Jump to: navigation, search

OpenDaylight Controller:Config:Main


The config subsystem of the OpenDaylight Controller provides two key features:

  1. A uniform way to express configuration that can be read in from a file updated at run time
  2. 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.

Dependency Resolution

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.

Configuration process


Initial configuration

Initial configuration for controller modules

YANG to Java code generator

Java code generator

Configuration subsystem

Component maps

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

User guide

User guide


Netconf Client



Frequently asked questions

All subpages

OpenDaylight Controller:Config:Component MapOpenDaylight Controller:Config:ConfigurationOpenDaylight Controller:Config:Configuration:Initial
OpenDaylight Controller:Config:DesignOpenDaylight Controller:Config:Examples:LogbackOpenDaylight Controller:Config:Examples:Netconf
OpenDaylight Controller:Config:Examples:Netconf:Example ConfigurationOpenDaylight Controller:Config:Examples:Netconf:Manual netopeer installationOpenDaylight Controller:Config:Examples:OpenFlow
OpenDaylight Controller:Config:Examples:Sample ProjectOpenDaylight Controller:Config:Examples:ThreadpoolOpenDaylight Controller:Config:Examples:Threadpool:Telnet
OpenDaylight Controller:Config:Examples:User guideOpenDaylight Controller:Config:FAQOpenDaylight Controller:Config:JMX Wrapper
OpenDaylight Controller:Config:JavaShimOpenDaylight Controller:Config:Java Code GeneratorOpenDaylight Controller:Config:Logback.xml
OpenDaylight Controller:Config:MainOpenDaylight Controller:Config:UnitTestingOpenDaylight Controller:Config:config.ini