The Java code for the configuration system is generated by the yang-maven-plugin and the yang-jmx-generator-plugin.
The input Yang module files are converted to java files by the definition of the module and the specified templates. the generated java code can represent interfaces, classes, or abstract classes used for configuration.
-=== Service interfaces generating
+===== Service interfaces generating
Service interfaces (SI) are generated from YANG "service-types". Each SI must be defined as "identity" with a "base" statement set to "config:service-type", or another SI. This is because a service must have a globally unique name.
Each SI must be annotated with @ServiceInterfaceAnnotation, and must extend AbstractServiceInterface.
}
----
-==== Module stubs generating
+====== Module stubs generating
Modules are constructed during configuration transaction. A module implements the ModuleMXBean interface. The ModuleMXBean interface represents getters and setters for attributes that will be exposed to the configuration registry by means of JMX. Attributes can either be simple types, or composite types.
Each ModuleMXBean must be defined in yang as "identity" with the base statement set to "config:module-type". Not only are ModuleMXBeans generated, but also ModuleFactory and Module stubs. Both are first generated as abstract classes with almost full functionality. Then their implementations, which are allowed to be modified by users, are generated, but only once.
-=== Runtime beans generating
+===== Runtime beans generating
Runtime JMX beans are purposed to be the auditors: they capture data about running module instances. A module can have zero or more runtime beans. Runtime beans are hierarchically ordered, and each must be uniquely identified.
A runtime bean is defined as a configuration augment of a module, from which interface RuntimeMXBean, RuntimeRegistrator, and RuntimeRegistretion are generated. Augment definition contains arguments representing the data of a module that must be watched.
-==== RPCs
+===== RPCs
Method calls in yang must be specified as top level elements. The context, where an RPC operation exits, must be defined in the RPC definition itself, and in the runtime bean that provides method implementation.
-=== OpenDaylight Controller: Configuration
+===== OpenDaylight Controller: Configuration
The Controller configuration operation has three stages:
* First, a Proposed configuration is created. Its target is to replace the old configuration.
Since there can be dependencies between modules, a change in a module configuration can affect the state of other modules. Therefore, we need to verify whether dependencies on other modules can be resolved.
The Dependency Resolver acts in a manner similar to dependency injectors. Basically, a dependency tree is built.
-=== APIs and SPIs
+==== APIs and SPIs
This section describes configuration system APIs and SPIs.
-==== SPIs
+===== SPIs
*Module* org.opendaylight.controller.config.spi. Module is the common interface for all modules: every module must implement it. The module is designated to hold configuration attributes, validate them, and create instances of service based on the attributes.
This instance must implement the AutoCloseable interface, owing to resources clean up. If the module was created from an already running instance, it contains an old instance of the module. A module can implement multiple services. If the module depends on other modules, setters need to be annotated with @RequireInterface.
ModuleFactory can also return default modules, useful for populating registry with already existing configurations.
A module factory implementation must have a globally unique name.
-==== APIs
+===== APIs
|===
| ConfigRegistry | Represents functionality provided by a configuration transaction (create, destroy module, validate, or abort transaction).
| RuntimeBeanRegistratorAwareConfiBean | The module implementing this interface will receive RuntimeBeanRegistrator before getInstance is invoked.
|===
-==== Runtime APIs
+===== Runtime APIs
|===
| RuntimeBean | Common interface for all runtime beans
| HierarchicalRuntimeBeanRegistration | Represents functionality for runtime bean registration and unreregistration from hierarchy
|===
-==== JMX APIs
+===== JMX APIs
JMX API is purposed as a transition between the Client API and the JMX platform. +
| Object names | Object Name is the pattern used in JMX to locate JMX beans. It consists of domain and key properties (at least one key-value pair). Domain is defined as "org.opendaylight.controller". The only mandatory property is "type".
|===
-==== Use case scenarios
+===== Use case scenarios
A few samples of successful and unsuccessful transaction scenarios follow: +
. On aborted transactions, TransactionController and JMXRegistrator are properly closed.
. Unregistration event is sent to ConfigRegistry.
-==== Default module instances
+===== Default module instances
The configuration subsystem provides a way for modules to create default instances. A default instance is an instance of a module, that is created at the module bundle start-up (module becomes visible for
configuration subsystem, for example, its bundle is activated in the OSGi environment). By default, no default instances are produced.
Module A has node A1. Module B augments node A1 by adding node X. Module C augments node A1 by adding node X. For clarity, it has to be known which node is X (for example: C:X).
For more details about encoding, see: http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3.1[Restconf 02 - Encoding YANG Instance Identifiers in the Request URI.]
-=== Mount point
+==== Mount point
A Node can be behind a mount point. In this case, the URI has to be in format <identifier>/*yang-ext:mount*/<identifier>. The first <identifier> is the path to a mount point and the second <identifier> is the path to a node behind the mount point. A URI can end in a mount point itself by using <identifier>/*yang-ext:mount*. +
More information on how to actually use mountpoints is available at: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf[ OpenDaylight Controller:Config:Examples:Netconf].
. CompositeNode can be normalized by adding additional information from DataSchemaNode.
. Restconf begins the transaction, and puts CompositeNode with InstanceIdentifier into it. The response on the request from the client is the status code which depends on the result from the transaction.
-=== Something practical
+
+// FIXME: Replace with coretutorials tutorial or point to openflow location
+==== Something practical
. Create a new flow on the switch openflow:1 in table 2.
Code Review / docs.git / commitdiff