| commit | dafefe16ce5d946271ca9ac5a4fd36ec2a92bee8 | [log] [tgz] |
|---|---|---|
| author | Zsolt Haraszti <zharaszt@ciena.com> | Mon Nov 14 21:29:58 2016 -0800 |
| committer | Zsolt Haraszti <zharaszt@ciena.com> | Wed Nov 23 10:20:30 2016 -0800 |
| tree | a0f218d28f01c9498ca63993e1c8987337be1158 | |
| parent | 7b1bab911a9e79da18247746f6b56168d24df049 [diff] |
Config/management model framework initial version This is the initial commit of the internal config model tree for Voltha. A system that borrows key concepts from Docker, repo, and git for multi-revision configuration handling with transaction (commit/abort) logic, tagging, and the ability to diff between config versions. Key features: * Stored model is defined using *annotated* Google protobuf (*.proto) files * Model is kept in memory as Python protobuf message objects * The whole configuration is arranged in a nested (tree) structure, made up of ConfigNode objects. Each ConfigNode holds its config data as (possibly nested) protobuf message object, as well as lists of "pointers" to its logically nested children nodes. What message fields are considered part of the node-local config vs. what is stored as a child node is controlled by "child_node" annotations in the *.proto files. * Each ConifgNode stores its config in immutable ConfigRevision obects, each revision being identified by a unique hash value, calculated from a unique hash value of its local configuration as well as the list of hash values of all its children node. * Collection type children nodes can be indexed (keyed) so that they can be addressed with "path" notation friendly to REST and other interfaces/APIs. Which field is used as key is defined in the parent message using "key" attribute of the "child_node" annotation. Currently string and integer type fields can be used as keys. * Changes to the model create new revisions in all affected nodes, which are rolled up as new revisions to the root node. * Root revisions can be tagged, tags can be moved * The root node by default keeps a rev, but provides a mechanism to purge untagged revs. * All branch and leaf nodes auto-purge interim revs not needed. A rev is not needed if no one refers to it. * Diffing between revs is supported, it yields RFC6902 jsonpatch objects. Diffing can be done between any revs. * The main operations are: CRUD (we call them .add, .get, .update, .remove) * Get can be recursive to an optionally limited depth. * There is support for Read-Only attributes (fields) * All CRUD operation support "path" based addressing. * There is support for an branch/leaf node perspective implemented by ConfigProxy. This proxy, when attached to an arbitrary node in the tree, provides all the CRUD operations in that context, that is, path args are used relative to that node. * Transaction support: All mutations made in a transaction are invisible to others until the transaction is committed. The commit is atomic (either all changes are applied to the tree or none). Conflicts between transactions are detected at the per-node level and a conflict results in rejecting the conflicting transaction (first one wins). * Registered callbacks: via the proxy objects an observer can register for pre- and post- operation callbacks. Also, there is a post-get callback which can be used to augment stored data with real-time data. I started hooking up the new config infrastructure to Voltha's CORE, but this is still in progress, as not all existing APIs have bee moved over yet. Note: I also lumped in some experimental files working with "Any" types in protobufs Change-Id: Ic547b36e9b893d54e6d9ce67bdfcb32a6e8acd4c
Voltha aims to provide a layer of abstraction on top of legacy and next generation access network equipment for the purpose of control and management. Its initial focus is on PON (GPON, EPON, NG PON 2), but it aims to go beyond to eventually cover other access technologies (xDSL, Docsis, G.FAST, dedicated Ethernet, fixed wireless).
Key concepts of Voltha:
Control and management in the access network space is a mess. Each access technology brings its own bag of protocols, and on top of that vendors have their own interpretation/extension of the same standards. Compounding the problem is that these vendor- and technology specific differences ooze way up into the centralized OSS systems of the service provider, creating a lot of inefficiencies.
Ideally, all vendor equipment for the same access technology should provide an identical interface for control and management. Moreover, there shall be much higher synergies across technologies. While we wait for vendors to unite, Voltha provides an increment to that direction, by confining the differences to the locality of access and hiding them from the upper layers of the OSS stack.
While we are still at the early phase of development, you can check out the BUILD.md file to see how you can build it, run it, test it, etc.
Contributions, small and large, are welcome. Minor contributions and bug fixes are always welcome in form of pull requests. For larger work, the best is to check in with the existing developers to see where help is most needed and to make sure your solution is compatible with the general philosophy of Voltha.