This page documents the collection of user interfaces available to configure and control CORD. The collection includes an extensible graphical interface, a RESTful programmatic interface, and a TOSCA-based configuration interface.
Graphical User Interface
The CORD GUI (which runs in the UI container of a CORD POD) consists of two major elements: (1) a global view that is auto-generated from the CORD data model, and (2) a set of customized views that are targeted at specific users or workflows. We call these displays views because each provides a different view of the underlying data model – the global view is a straightforward representation of the data model (each page typically maps directly to a Django model), while each customized view typically combines and cuts across models for the sake of some particular user community.
Global View
The global view is a collection of pages generated by the Django Admin package. It also takes advantage of the Django Suit to extend Django Admin and stylize the content. All the templates can be found in /xos/templates/admin. The global view includes pages for each of the core models (e.g., Slices, Services, Users, Deployments, Sites), and can be used to read update and delete objects in the CORD data model. The core models displayed through the global view are registered in the system through /xos/core/admin.py.
In addition to pages that correspond to the core models, the global view also includes a set of pages for each Service that has been on-boarded into CORD. Part of the on-boarding process is to define the service-specific extensions to the Django Admin framework. These extensions can be found in the xos/admin.py file of each service repository (e.g., see the ExampleService repository). Typically, a service will define one page that can be used to manage the service as a whole, and a second page that can be used to mange individual tenants (instances) of that service.
Custom Views
Anytime there is a need to present combined information that crosses multiple models, one can define (and load in CORD) a custom Javascript-driven view. Each such view is a standalone AngularJs application that communicates with the CORD data model through REST APIs.
More information about how to develop custom views can be found at http://guide.xosproject.org/devguide/addview/, or by watching this tutorial
REST APIs
A REST API defines a programmatic northbound interface to CORD. The API defines defines a set of REST endpoints, prefixed with /api and divided into four main categories:
/api/core – Core models; this is an auto-generated endpoint
/api/utility – Utility end-points;not necessarily related to a model but useful in managing the system (e.g., Login/Logout, Service On-boarding)
/api/service – Service-related endpoints; defined on a per-service basis (see Service On-Boarding)
/api/tenant – Tenant/Instance-related endpoints; defined on a per-service basis (see Service On-Boarding)
The API documentation is available online at http://docs.xos.apiary.io/# or (with an XOS instance running) you can visit the documentation at /api. All service-specific API-related code lives in the /xos/api directory of the service repository (e.g., see the ExampleService repository).
TOSCA
TOSCA (Topology and Orchestration Specification for Cloud Applications) is a YAML-based language that CORD uses primarily to configure the set of services running in a CORD POD. You can find TOSCA recipe examples in the Service Profile repository. Each service also defines a service-specific on-boarding recipe as part of its service definition (see Service On-Boarding).
Note that TOSCA templates are typically pushed to CORD through a dedicated REST API.
Also, the service page of the GUI's global view provides a button that can be used to export the TOSCA recipe for a specified service.
Testing the User Interface
The UI comes with two batteries of tests:
- API tests – Test API functionalities performing defined requests
- UI Tests – Test the shared UI Library and Custom Views
A set of end-to-end UI test for the Global View is currently under development.
API Tests
API endpoints are documented through a Blueprint format, and that documentation is used to automatically generate tests. This is done using a tool called Dredd. All the code related to API tests and documentation can be found in /xos/tests/api.
This tests are executed for each Gerrit review request on the XOS and Service Profile repositories. They can also be executed on demand in your local environment using the test-standalone configuration in the Service Profile repository.
To create the environment for the test to run:
cd /service-profile/test-standalone docker rm -f $(docker ps -aq) // clean all the existing containers make containers make
This will build a UI container slightly different from the UI container (Node Js is required to execute the tests). Once the environment is ready, you can execute it with:
make test
Note that if you make change to the XOS codebase is required to rebuild the environment before running the test.
UI Test
As the Custom Views are developed using AngularJs, it was a natural choice to use Karma and Jasmine as testing frameworks.
The code related to a single Custom View can be found in /views/ngXosViews/<viewName>/spec.
These tests don't require a full XOS or CORD installation, so they can be executed on your host machine. The only requirement is to have Node Js > 4.x.x installed.
Testing a Single Custom View
cd /views/ngXosViews/<viewName> npm test
Note that these tests run in watch mode – they will not exit after being executed but will keep listening for file changes and when that happen they are triggered again.
Jenkins CI Tests
All the tests described above are intended for development purpose, so a different configuration is provided to run all of them in a single shot and exit with a status code.
These tests are executed any time a Gerrit review request on the XOS repository is submitted. To execute the tests locally:
cd xos/xos/tests/ui/ npm install bower install npm test