CORD : Yang Models for CORD

This is a working document where we plan to record our latest thinking on how to build Yang models for CORD and CORD services.

Reference Implementation: YANG model-driven CORD (unofficial Github page)

This is an exploratory effort, that is answering the following questions.

How are the models going to change?

In the process of converting the Django-based models into YANG models, we have an opportunity to re-factor our models. Beyond the obvious housecleaning, we should identify general "classes" of changes we have an opportunity to make.

Make "declarative" versus "feedback" state distinction explicit. In general, it would be nice to have an easy way of annotating fields in a model in a way that can be looked up via the REST API (Click here for more information.)
An annotation scheme that replaces our dependency annotations in Django. The dependency annotations specify a set of dependencies for each model. A dependency is a 4-tuple consisting of a source model, a destination model, a source field and a destination field. More generality might be useful. E.g. if we could specify dependencies as XPath expressions.
Information about the Synchronizer that synchronizes that model (if it is decided that this information be stored in the model, and not in the synchronizer). This information also implies whether the synchronizer is a potential watcher or an actuator.

What are our options for auto-generating a graphical interface (analogous to Django's Admin UI)?

Starting from a YANG model definition is possible to automatically generate a UI to perform CRUD operations on the model. Two possible solutions are currently under discussion:

Generating the necessary view on the server
1. This mean that anytime the server is started (or a model definition change), UI components are generated, bundled togheter in a Single Page Application and served to the browser.
Create smart UI components that are able to discover the needed configuration
1. This means to have a base Single Page Application that is able to configure itself based on API responses.

What are our options for making the data model persistent?

The YANG models can synchronize to any underlying system, be it a database (Postgres) or something else. It just means writing the right object event handlers.

What are our options for integrating YANG with the Synchronizer mechanisms?

The cleanest solution would be for YANG and the Synchronizers to both access the database (Postgres). This would still leave the problem of re-implementing the Synchronizer framework to do its dependency analysis and scheduling based on YANG rather than Django.

It is worth remembering that before long we plan to re-engineer Synchronizers to use the REST API instead of direct access to the database.

What are our options for an eventual Django-to-YANG transition?

One proposal is to synchronize with the existing REST API. This would run YANG as a layer on top of the existing system, resulting with REST running on top of REST. Very modular, and this approach is at least good for development.

It is also possible to run the YANG-based models stuff side-by-side with the existing implementation, both directly accessing Postgres. This would take more care, to make sure the two systems coordinate sharing of the database appropriately. We already have that requirement with the synchronizer (both synchronizer and XOS UI talk directly to Postgres).

One question that crops up here is - which interface would the Synchronizer use. In the short term, probably Django. But in the long term it could use Django/REST or YANG/REST.