Overview

 In ONOS, various abstractions collect configuration information pertaining to the network and network elements and store them in the implementation defined system wide models. But often in the brown fields, applications create or collect similar configuration information  and work with their own individual information models (let us call this the "elastic configs"). Often these models are heterogeneous and most of them do not directly confirm to the models/abstraction within ONOS. The purpose of the elastic config subsystem is to provide suitable abstractions that would enable ONOS to consume/produce the "elastic configs" in a structured and extensible manner. Parking such "elastic configs" within ONOS would also allow opportunities for other abstractions (like drivers, providers etc.) to consume or apply them. 

 Components

The main components of this subsystem include the elastic config service, elastic config manger, elastic config store interface and the distributed elastic config store. Elastic config service is the gateway for applications to inject elastic configs to ONOS. Elastic config manger implements this service and is responsible for managing the distributed elastic config store; apart from managing the store, the manger can also do additional south facing processing. Elastic config store provides the APIs and the Distributed elastic config store provides the implementation of the store. the store implementation is wrapping the Document Tree primitive and is built on top of the ONOS Distributed storage implementation. 

Two other important abstractions are the ConfigNode and ConfigNodePath. ConfigNode represents the in-memory format of "elastic config" that applications and the implementation of the “elastic config service” would deal with. ConfigNodePath represents the in-memory format of “the key to an elastic config node”; in general it would contain the absolute path to a parent and the relative path to the specific node.

ConfigFilter is the abstraction to specify the kind of filtering that needs to be applied while working with elastic config nodes. In its current state it supports key based filtering of nodes and can be extended to include various types of content based filtering as well. 

ConfigStoreType would indicate whether the given elastic config is a DEVICE_CONFIG or if it is a SERVICE_CONFIG. TraversalMode would indicate, from a given path, whether the nodes are to be recursively traversed or not. 

APIs

Elastic config service supports the following APIs currently:

/**
 * Adds a new node to the elastic config store.

 */

CompletableFuture<Boolean> addNode(ConfigStoreType store, ConfigNodePath path, ConfigNode node);

 /**
 * Removes  a node from the elastic config store.
 */
CompletableFuture<ConfigNode> removeNode(ConfigStoreType store, ConfigNodePath path);

/**
 * Creates/Updates  a node in the elastic config store.
 */
CompletableFuture<ConfigNode> updateNode(ConfigStoreType store, ConfigNodePath path, ConfigNode node);

/**
 * Creates nodes in the elastic config store, recursively by creating
 * all missing intermediate nodes in the path.
 */
CompletableFuture<Boolean> createRecursive(ConfigStoreType store,ConfigNodePath path, ConfigNode node);

/**
 * Delete nodes in the elastic config store, recursively by deleting all
 * intermediate nodes in the path.
 */
CompletableFuture<Boolean> deleteRecursive(ConfigStoreType store, ConfigNodePath path);

/**
 * Creates/Updates nodes in the elastic config store, recursively by creating
 * all missing intermediate nodes in the path.
 */
CompletableFuture<Boolean> updateRecursive(ConfigStoreType store, ConfigNodePath path, ConfigNode node);

/**
  * Returns a value node or subtree under the given path.
  */
CompletableFuture<ConfigNode> getNode(ConfigStoreType store, ConfigNodePath path, TraversalMode mode, ConfigFilter filter);

/**
 * Returns the number of children under the given path, excluding
 * the node at the path.
 */
CompletableFuture<Integer> getNumberOfChildren(ConfigStoreType store, ConfigNodePath path, ConfigFilter filter);

/**
 * Registers a listener to be notified when the subtree rooted at
 * the specified path is modified.
 */
CompletableFuture<Void> addConfigListener(ConfigStoreType store, ConfigNodePath path, ElasticConfigListener listener);

/**
   * Unregisters a previously added listener.
   */
CompletableFuture<Void> removeConfigListener(ElasticConfigListener listener);

Use Case

In its current state, the following demo use case is planned to be supported

Document Tree primitive

This subsystem makes use of the DocumentTree primitive.  The primitive consists of an implementation of AsyncDocumentTree (AtomixDocumentTree) residing on the client machine which submits commands to the remote Copycat state machine (AtomixDocumentTreeState), responsible for maintaining distributed state.  The commands submitted to the primitive are found in AtomixDocumentTreeCommands, it should be noted that there will not necessarily be a one to one correspondence between the commands provided in the AsyncDocumentTree API and the command classes, in many cases a single command class can encapsulate the functionality of several API calls.

Behavior

The DocumentTree primitive supports a tree structure which allows nodes with arbitrary numbers of children.  The primitive also provides efficient prefix filtering by using qualified names which identify the ancestry of a node (as demonstrated in the image below) which enables listening for notifications from specified subtrees.  The structure supports sequential query consistency but makes no guarantees about the linearizability of queries. 

Next Steps