1 Commits

Author	SHA1	Message	Date
Ben Thomasson	48d801271c	Imports prototype from ansible-network-ui ... The ansible-network-ui prototype project builds a standalone Network UI outside of Tower as its own Django application. The original prototype code is located here: https://github.com/benthomasson/ansible-network-ui. The prototype provides a virtual canvas that supports placing networking devices onto 2D plane and connecting those devices together with connections called links. The point where the link connects to the network device is called an interface. The devices, interfaces, and links may all have their respective names. This models physical networking devices is a simple fashion. The prototype implements a pannable and zoomable 2D canvas in using SVG elements and AngularJS directives. This is done by adding event listeners for mouse and keyboard events to an SVG element that fills the entire browser window. Mouse and keyboard events are handled in a processing pipeline where the processing units are implemented as finite state machines that provide deterministic behavior to the UI. The finite state machines are built in a visual way that makes the states and transitions clearly evident. The visual tool for building FSM is located here: https://github.com/benthomasson/fsm-designer-svg. This tool is a fork of this project where the canvas is the same. The elements on the page are FSM states and the directional connections are called transitions. The bootstrapping of the FSM designer tool and network-ui happen in parallel. It was useful to try experiemental code in FSM designer and then import it into network-ui. The FSM designer tool provides a YAML description of the design which can be used to generate skeleton code and check the implementation against the design for discrepancies. Events supported: * Mouse click * Mouse scroll-wheel * Keyboard events * Touch events Interactions supported: * Pan canvas by clicking-and-dragging on the background * Zooming canvas by scrolling mousewheel * Adding devices and links by using hotkeys * Selecting devices, interaces, and links by clicking on their icon * Editing labels on devices, interfaces, and links by double-clicking on their icon * Moving devices around the canvas by clicking-and-dragging on their icon Device types supported: * router * switch * host * racks The database schema for the prototype is also developed with a visual tool that makes the relationships in the snowflake schema for the models quickly evident. This tool makes it very easy to build queries across multiple tables using Django's query builder. See: https://github.com/benthomasson/db-designer-svg The client and the server communicate asynchronously over a websocket. This allows the UI to be very responsive to user interaction since the full request/response cycle is not needed for every user interaction. The server provides persistence of the UI state in the database using event handlers for events generated in the UI. The UI processes mouse and keyboard events, updates the UI, and generates new types of events that are then sent to the server to be persisted in the database. UI elements are tracked by unique ids generated on the client when an element is first created. This allows the elements to be correctly tracked before they are stored in the database. The history of the UI is stored in the TopologyHistory model which is useful for tracking which client made which change and is useful for implementing undo/redo. Each message is given a unique id per client and has a known message type. Message types are pre-populated in the MessageType model using a database migration. A History message containing all the change messages for a topology is sent when the websocket is connected. This allows for undo/redo work across sessions. This prototype provides a server-side test runner for driving tests in the user interface. Events are emitted on the server to drive the UI. Test code coverage is measured using the istanbul library which produces instrumented client code. Code coverage for the server is is measured by the coverage library. The test code coverage for the Python code is 100%.	2018-03-23 17:00:14 -04:00