48d801271c
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%. |
||
|---|---|---|
| .. | ||
| README.md | ||
| requirements_ansible_git.txt | ||
| requirements_ansible_uninstall.txt | ||
| requirements_ansible.in | ||
| requirements_ansible.txt | ||
| requirements_dev.txt | ||
| requirements_git.txt | ||
| requirements_isolated.txt | ||
| requirements_setup_requires.txt | ||
| requirements_tower_uninstall.txt | ||
| requirements.in | ||
| requirements.txt | ||
The requirements.txt and requirements_ansible.txt files are generated from requirements.in and requirements_ansible.in, respectively, using pip-tools pip-compile. The following commands should do this if ran inside the tower_tools container.
NOTE: before running pip-compile, please copy-paste contents in requirements/requirements_git.txt to the top of requirements/requirements.in and prepend each copied line with -e . Later after requirements.txt is generated, don't forget to remove all git+https://github.com...-like lines from both requirements.txt and requirements.in (repeat for requirements_ansible_git.txt and requirements_ansible.in)
At the end of requirements/requirements.in, pip and setuptools need to have their versions pinned.
virtualenv /buildit
source /buildit/bin/activate
pip install pip-tools
pip install pip --upgrade
pip-compile requirements/requirements.in > requirements/requirements.txt
pip-compile requirements/requirements_ansible.in > requirements/requirements_ansible.txt
Known Issues
-
Remove the
-efrom packages of the form-e git+https://github.com...in the generated.txt. Failure to do so will result in a "bad" RPM and DEB due to thepip installlaying down a symbolic link with an absolute path from the virtualenv to the git repository that will differ from when the RPM and DEB are build to when the RPM and DEB are installed on a machine. By removing the-ethe symbolic egg link will not be created and all is well. -
As of
pip-tools1.8.1pip-compiledoes not resolve packages specified using a git url. Thus, dependencies for things likedm.xmlsec.bindingdo not get resolved and output torequirements.txt. This means that:- can't use
pip install --no-depsbecause other deps WILL be sucked in - all dependencies are NOT captured in our
.txtfiles. This means you can't rely on the.txtwhen gathering licenses.
- can't use
-
Package
docutils, as an upstream ofboto3, is commented out in bothrequirements.txtandrequirements_ansible.txtbecause the official package has a bug that causes RPM build failure. Here is the bug report. Please do not uncomment it before the bug fix lands. For now we are using a monkey-patch version ofdocutilsthat comes with the bug fix. It's included inrequirements_git.txtandrequirements_ansible_git.txt.