community 
Select multiple nodes to drag/drop/reposition nodes on a canvas
What is the problem?
----------------------
- Scale issues representing a topology at 100+ nodes (UI sluggish/unresponsive)
- Links aren't represented on the canvas at 200 node topology
- Cannot select multiple nodes and reposition them
- Would like the ability to select multiple nodes to drag/drop/reposition nodes on a canvas.
- Copy and paste selected nodes to duplicate resources on canvas (ctr + c/ctrl + v like function)
- Draw and color shapes to delineate logical/organizational boundaries for the topology.
These are the artifacts necessary to reproduce the Cloudshell experiences I talk about.
Sample Blueprints:
Shell:
Example task(s):
- Using the Cloudshell UI, take the 100/200 node topologies and divide the nodes up into 5 general groups, to represent 5 Data Center regions.
Some examples from alternative solutions:
https://www.eve-ng.net/wp-content/uploads/2019/11/34_sd-wan_viptela.png
https://www.gns3.com/api/v2/assets/photo/58d42f9925e6cba6338b7a4f/GNS3-Topology.PNG
Users are not incentivized to use Cloudshell over other alternatives for virtual network lab testing as users consider it is cumbersome to deal with relatively small topologies on Cloudshell(20-30 nodes) when compared with the existing user interfaces they are using.
This idea post goes into issues of scale, but delivery of the item #3 would be a good start as items #1 & #2 likely involve a major UI technology overhaul on the backend.
Things to note:
All the resources we are dealing with in this specific use case are abstract/ephemeral in nature. (virtual network operating systems...nxosv, iosxrv, csr1000v, vmx, veos...etc)
Why is it a problem?
------------------------
We are looking to use Quali in our organization like Juniper's vLabs and Cisco's dCloud. Instead of fixed topologies, we would allow users to define their own blueprints.
With the current alternatives :
coupled with some of the missing UI features to deal with multiple nodes + issues pointed out here , there is little incentive for our users to switch from their personally hosted labs onto the Quali platform for virtual lab testing.
The one major drawback to the emulation softwares that our users are using (GNS3/EVE-NG) is the fact that these solutions have not been able to address the problem of linear scaling for virtual node provisioning/interconnection on a massive scale. The net result is that many people run their production emulations on a single box (or 2-3 at max...often times in isolated environments) versus in a massively shared distributed computing cluster. (the key differentiating word here is "massive")
This often results in scaled down replications of production environments as well as several duplicated configuration setups due to the lack of shared environments. These environments can easily be consolidated with Quali's Cloudshell environment provisioning/scheduling capabilities.
On top of that home lab users are generally limited to topology size of 50~100 nodes when using these emulation software, due to the compute limitations of their hardware. Generally this acceptable for most home users. However, Rackspace is looking to run much larger/higher fidelity production topologies (1000-5000).
We have been able to address the linear scaling compute issue to emulate/interconnect several hundred virtual nodes (which requires much more fine tuning than the out of the box Cloudshell vSphere integration).
We are confident we can use the Cloudshell Automation API to integrate these back end technologies to the Cloudshell front-end UI. It is this ability to define arbitrarily large topologies (while simply adding more compute when needed) that gives this solution a very distinct appeal to our users over the alternative platforms (GNS3/EVE-NG). Were these front end UI enhancements made to support several hundred nodes, it will undoubtedly drive rapid adoption of the Quali platform within our organization.
As it stands the Cloudshell UI is just not able to represent the number of nodes we would like to see without the UI lagging out.
The topology sizes we plan to run for our architect/engineering team, can be 150-500 nodes at just a backbone level (excluding DC), with all backbone nodes required to be represented individually on a canvas (not just as a consolidated bubble). Ideally this would look like a google maps pan/zoom behavior.
These UI issues within Cloudshell are considered minor annoyances with small scale topologies, but can still be attractive to our users as a training/testing option with the snapshot and environment provisioning functions. This will help drive some adoption. However, these web UI issues present major barriers to adoption when spinning up medium to large scale topologies.
How do you solve the problem today?
- Normal users:
Select individual nodes and reposition them. Even this is considered to be cumbersome in a 20 - 30 node topology.
Have a separate diagram up (Juniper vLabs is a good example)
- Power users/devs:
Programatically reposition nodes(resources) by translating a graph data structure (node/links) and node coordinates from another drawing program into Packaging API commands that would be reflected on a Blueprint.
This is how the 100/200 node topologies were generated. We originally started out with a 500 node scale test, but trimmed it back to 100 when we encountered UI issues.
How would you ideally solve the problem?
This is visually one of the closest examples I could find.
https://observablehq.com/@grantcuster/using-three-js-for-2d-data-visualization
This is based on threejs, which is a WebGL based JS API, but can be accomplished with other technologies like HTML5 canvas. My research into this suggests that WebGL is best suited for the task, with SVG based technologies not being suited at all for large scale topology rendering.
There are plenty of other articles on the subject.
The other way I would envision large scale topologies being rendered is using a google maps style pan/zoom behavior.
This would include a search bar that would center in on a resource when the search function is called. (Example: search "Tel Aviv" in google maps)
My group was originally planning to develop a front end UI, but it is just not our forte. I understand Quali Cloudshell is more than just a UI, and lots of work has gone into the development of the backend APIs/documentation.
We would like to integrate our back-end network emulation technologies with the Cloudshell UI and take advantage of the scheduling components to give users access to these large scale virtual labs.
How big is the problem (frequency of impact, who is impacted)
Users will come and see the new Quali platform and some will be early adopters due to the enviorment provisioning capabilities, but without a "killer feature" (in this case, the ability to render large virtual topologies onto a single canvas), many users will likely view the Quali platform as a novelty, not relevant to their line of work and continue defaulting to their own home lab solutions.
