- 1 Overview
- 2 Terminology
- 3 Configuration process
- 4 Initial configuration
- 5 YANG to Java code generator
- 6 Configuration subsystem
- 7 Component maps
- 8 Configuration outside of config-subsystem domain
- 9 User guide
- 10 Examples
- 11 Netconf Client
- 12 FAQ
- 13 All subpages
The config subsystem of the OpenDaylight Controller provides two key features:
- A uniform way to express configuration that can be read in from a file updated at run time
- A uniform way to express requirements on other services
Almost all applications have to read some configuration information, which is usually done by means of config files, for example, xml or properties files. For simple applications, just reading in a single file without any formally-defined schema is easy. As applications grow in complexity, it is useful to include more features: formally defining the configuration options, allowing for runtime configuration and atomic updates.
Similarly, most applications of any complexity have dependencies, which they would like to avoid directly embedding. This is especially true for applications designed to run on a platform/runtime, for example, OpenDaylight. Existing tooling, like the dependency management of OSGi solve some of these issues, but also have known issues. For instance, it is difficult to figure out when a dependency has fully loaded and non-deterministic load orders can create heisenbugs.
Expressing what other applications/services an application depends on, and whether those dependencies are required or optional is a critical part of assembling component-based systems like OpenDaylight. The config subsystem provides a relatively simple way to express such dependencies, and have the implementation made available to them locally.
All configuration (and dependencies) are defined in a yang schema which is specified as part of an application that is enabled to work with the config subsystem. This schema does not provide the actual values or dependencies, but provides the range of acceptable values and defines the dependencies. The initial values for these are provided by an xml file which corresponds to the schema defined in the YANG file.
In addition to the initial configuration specified in the xml file, newer configurations can be provided, either in total or just changing some parts, by using NETCONF to update the configuration. Applications are notified of the change and can either process the change appropriately or reject it.
Comparison to OSGi Config Admin
The OSGi framework provides configuration service (Config Admin), and allows runtime module configuration. However, it still lacks a validation process: a new module configuration can negatively affect other modules. It also does not solve the problems relating to the atomicity of the change.
Module: A compact part of a system, whose configuration is managed by the configuration subsystem.
Module factory: Important for creating module instances. Module factories are uniquely identified by names.
Service: Public API, which is used to access module instances (similar to interface in Java). Any module can implement or provide multiple services.
Configuration: Application state represented by the definition of modules, properties, and the relations among them.
YANG to Java code generator
List of components present in config and netconf subsystem with additional useful information (description, names of experts for each component, documentation and others)
Configuration outside of config-subsystem domain
- Thread pools configuration using yuma yangcli-pro and telnet as netconf clients
- Logback configuration using jolokia, telnet and yuma yangcli-pro as netconf clients
- Netconf client (NCC) configuration
- Example "config subsystem aware" maven project built from ground
|OpenDaylight Controller:Config:Component Map||OpenDaylight Controller:Config:Configuration||OpenDaylight Controller:Config:Configuration:Initial|
|OpenDaylight Controller:Config:Design||OpenDaylight Controller:Config:Examples:Logback||OpenDaylight Controller:Config:Examples:Netconf|
|OpenDaylight Controller:Config:Examples:Netconf:Example Configuration||OpenDaylight Controller:Config:Examples:Netconf:Manual netopeer installation||OpenDaylight Controller:Config:Examples:OpenFlow|
|OpenDaylight Controller:Config:Examples:Sample Project||OpenDaylight Controller:Config:Examples:Threadpool||OpenDaylight Controller:Config:Examples:Threadpool:Telnet|
|OpenDaylight Controller:Config:Examples:User guide||OpenDaylight Controller:Config:FAQ||OpenDaylight Controller:Config:JMX Wrapper|
|OpenDaylight Controller:Config:JavaShim||OpenDaylight Controller:Config:Java Code Generator||OpenDaylight Controller:Config:Logback.xml|
|OpenDaylight Controller:Config:Main||OpenDaylight Controller:Config:UnitTesting||OpenDaylight Controller:Config:config.ini|