Configd
Configd is the configuration management service for DANOS. It handles configuration access, authorization, accounting, sessions, transactions, and dispatch. Configd also manages access to other YANG modeled information such as operational data and RPCs. Configd is the backend implementation for the various Management APIs available to developers.
Configd does not interpret the configuration supplied to it, it treats all configuration generically validating it according to the YANG data-model for the system. Responsibility for applying the configuration falls to the VCI components that register ownership over the configuration for a given YANG module.
Overall Architecture
The configd process consists of several processes, each fulfilling a role. Those processes are as follows.
Server
The "Server" process listens for new connections and spawns a new goroutine to handle each connection. Each connection goroutine validates the credentials of the connecting process and then calls methods on the "Dispatcher" object corresponding to the request made by the client.
Dispatcher
The "Dispatcher" objects implement the Management API methods. There is one dispatcher per connection. The dispatcher implements some of the non-session specific API calls, such as access to the YANG schema information via the Configd API.
Candidate Sessions
A connected client provides a session ID that is used when session specific requests are made. This id is used to resolve the actor associated with a session via the session manager. This actor provides serialized access to the session's "candidate" configuration tree.
Running Session
A special read only session with the ID of "RUNNING" is used to provide an actor through which access to the running tree is provided.
Commit Manager
The commit manager is an actor that provides serialized writes to the "running" configuration tree. The commit manager is responsible for dispatching configuration to the candidate components for realization on the system.
Session Manager
The session manager handles session access, creation, and teardown.
Authorization and Accounting
Authorization and accounting is performed by according to the AAA configuration. AAA plugins are used for non-local authentication and accounting. Configd also implements a local configuration path based authorization service, which is used when configured.
Configuration Access
Accessing the configuration may be done from any connection. Connections not associated with a particular session ID will default to accessing the "running" configuration tree. If associated with a session the default access will be to the session's "candidate" configuration tree.
Configuration Manipulation
Configuration data in DANOS is accessed and manipulated via Configd. Configuration manipulation is centered around the concept of a "session". When a user wishes to manipulate the configuration of the system, they create a named "session" in configd. This "session" name must be unique and persists connections to configd. In this "session" the user gets a private "candidate" configuration tree which they may manipulate as desired. Once the "candidate" tree reflects the changes that a user wishes to be made to the system they may commit those changes. When commit completes the "candidate" tree in all "sessions" are rebased onto the new "running" tree taking all the "candidate" tree's changes. When one is finished making changes to a "session" they must "teardown" the session. Configuration access does not require a "session" and will default to accessing data from the "running" tree. A dummy "running" session exists to keep the interface to this tree consistent with access to "candidate" trees. The "running" tree can only be changed via the "commit" operation.
Conceptually configuration manipulation looks like the following diagram.
Commit semantics
The model for configuration in DANOS is that it is treated as the user's desired system state. VCI components then act as agents for the various parts of the configuration trying to bring about the required changes as the system's state evolves with time. Therefore, configuration must only be internally consistent and not rely on the current state of the system to determine whether it is valid. Committing changes in DANOS is a two stage process:
Changes are checked for validity according to the constraints in the data-model and any additional static checks the VCI component managing that portion of the configuration performs.
Changes are dispatched to components as the new desired configuration they must reconcile with the state of the system. If it is not possible to reconcile all changes given the state at the time of the commit then those changes are deferred until the circumstances change.
When a commit is performed, the commit manager process within configd is responsible for serializing changes to the running tree. This process will "validate" the requested changes and once declared valid, dispatch the configuration the the correct VCI components for realization on the running system. Once the dispatch is completed, the new "running" tree is stored and all "candidate" trees are rebased.
Operational State Data Access
Operational state data is also modeled in YANG and exposed from VCI components via the VCI bus. To retrieve this information in a cohesive form, configd provides a single interface that allows one to access the returned information. Configd will query all the VCI components required when a given path for operational state is requested and then return the merged result of querying all the components.