- Considering ODL controller a network device, its management should be exposed in a standardized manner. Management of ODL is handled by the config subsystem and exposed by NETCONF and RESTCONF using YANG as data definition language.
- Config subsystem gets activated using OSGi Activators and there is only one instance of config subsystem per controller node/JVM.
- Config Subsystem acts as a netconf server and Config Persister as a netconf client.
- config-netconf-connector provides RPC handles for config subsystem & connects to config subsystem using JMX interface, where it looks for ConfigRegistry and uses it to edit the current state of configured modules. Config-netconf-connector is an extension for the netconf server and provides handlers for editing and reading the data in config subsystem. It translates the netconf rpcs into java calls on config-subsystem.
- Config subsystem is accessible in 4 ways:
- NETCONF northbound
- RESTCONF northbound
- JMX (as JMX is the core of config subsystem)
- From the code
- Config persister:
- Automates startup of infrastructural services, plugins and applications by pushing initial configuration (consists of a few edit-config rpcs) to the northbound NETCONF interface of config subsystem.
- Stores current configuration snapshot from ODL while its running
- After every change of configuration, a notification is sent to config-persister with current snapshot to store. Notifications are carried over JMX.
- It retrieves the base configuration from the config.ini property file, and tries to load the configuration for the config subsystem
- Managed modules are config-subsystem aware components, that provide configurable modules into the config subsystem.
- Initial configuration of controller is done by reading xml files from configuration/initial folder. On startup, the XML files in the configuration/initial directory are loaded by the ConfigPersisterActivator. A ConfigPusher instance is instantiated to push the configs via the NetConf subsystem to the ConfigRegistryImpl.
- While processing the configuration xml file, related ModuleFactory class is located and instantiated and the createModule method is called to create a Module instance. Module.createInstance() method is then called to create and wire the service under consideration.
- ModuleInfoBundleTracker class in the config subsystem scrapes the META-INF/services/org.opendaylight.yangtools.yang.binding.YangModelBindingProvider resource from bundles on startup and reads the class name(s) defined in the file. For each YangModelBindingProvider class specified, the MD-SAL creates an instance and calls getModuleInfo() to return the singleton $YangModuleInfoImpl instance. This class has methods to obtain static configuration information about the yang module, e.g. name, revision, imports etc, as well as a getModuleSourceStream() method that provides an input stream to the META-INF/yang/*.yang file. Once the MD-SAL knows about a yang module and its definitions, it can wire it up to RestConf and other parts of the system.
- This mechanism was slightly updated for the Karaf distribution. Initial config files are not picked up from file-system but rather from features containing bundles with initial config files. A hook for an install feature event was implemented to scan incoming features. Config-persister is an extensible component that can be configured to use any storage-adapter internally to load initial configuration and the feature-storage-adapter was implemented in this case.
- In the case of multiple initial configuration files that depend on one another, their resolution order can be ensured by the names of the files. Files are sorted by their names in ascending order (for example, 00.xml, then 01.xml..). This means that every configuration file will have the visibility of modules from all previous configuration files via aliases. You basically want to order the config files such that dependencies (as inferred by the required-capabilities) are deployed first
- Services are not imported from the OSGi registry, but all services from config subsystem are published into it.
- In the configuration xml file, “modules” are defined as sort of collection of configurations for an instance of an implementation & “service” is a Public API, which is used to access module instances (similar to interface in Java). Any module can implement or provide multiple services..
- The Configuration subsystem provides a way for modules to create default instances. Default instance is an instance of a module that is created at the module bundle startup (module becomes visible for configuration subsystem for example, its bundle is activated in OSGi environment).
Important diagrams (Click on images for better visualization)
Questions (Answered by Maros Marsalek)
Q1. What is the responsibility of OSGI Service Registry now that all the modules are managed by Config Subsystem using config registry?
Ans. OSGi service registry should be avoided and config subsystem should be used instead for configuration and dependency injection.
Q2. Is there any particular reason we chose config subsystem to implement a netconf server?
Ans. Config subsystem is the manager for modules/plugins inside ODL. We wanted to expose it in a standardized manner and Netconf was chosen as a standard interface. That said, netconf server is pluggable and a plugin can be implement to expose netconf for MD-SAL (planned).
Q3. Exact location of file – META-INF/services/org.opendaylight.controller.config.spi.ModuleFactory
Ans. Every JAR file that contains yang files and was processed with yang-maven-plugin with config subsystem code generator, contains this file inside.
- How to use NETCONF in ODL to configure application(Modules)
- How to use RESTCONF in ODL to spawn and configure new instance of a Module(netconf connector)
- How to use RESTCONF in ODL to reconfigure a Module instance(netconf connector)
Creating config subsystem aware applications