Jump to: navigation, search

OpenDaylight Controller:Config:Configuration:Initial

Initial configuration for controller

There are two ways of configuring the controller:

  • Using config.ini the property file to pass configuration properties to the OSGi bundles besides the config subsystem.
  • Using the configuration persister to push the initial configuration for modules managed by the config subsystem.

Using config.ini property file

The config.ini property file can be used to provide a set of properties for any OSGi bundle deployed to the controller. It is usually used to configure bundles that are not managed by the config subsystem.

Using configuration persister

Configuration persister is a default service in the controller, and is started automatically using the OSGi Activator. Its purpose is to load the initial configuration for the config subsystem and store a snapshot for every new configuration state pushed to the config-subsystem from external clients. It retrieves the base configuration from the config.ini property file, and tries to load the configuration for the config subsystem. The configuration for the config subsystem is pushed as a set of edit-config netconf rpcs followed by a commit rpc since the config persister acts as a netconf client.

Configuration persister lifecycle:

  1. Start config persister service at config-persister-impl bundle startup.
  2. Retrieve the base configuration of adapters from the config.ini property file.
  3. Initialize the backing storage adapters.
  4. Initialize the netconf client, and connect to the netconf endpoint of the config subsystem.
  5. Load the initial configuration snapshots from the latest storage adapter.
  6. Send the edit-config rpc with the initial configuration snapshots.
  7. Send the commit rpc.
  8. Listen for any of the following changes to the configuration and persist a snapshot.

Configuration Persister interactions:
Persister.jpg

Current configuration for controller distribution

The config.ini property file contains following configuration for the configuration persister:

netconf.config.persister.active=1,2
 
netconf.config.persister.1.storageAdapterClass=org.opendaylight.controller.config.persist.storage.directory.autodetect.AutodetectDirectoryStorageAdapter
netconf.config.persister.1.properties.directoryStorage=configuration/initial/
netconf.config.persister.1.readonly=true
 
netconf.config.persister.2.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.xml.XmlFileStorageAdapter
netconf.config.persister.2.properties.fileStorage=configuration/current/controller.currentconfig.xml
netconf.config.persister.2.properties.numberOfBackups=1

With this configuration, the configuration persister initializes two adapters:

  • AutodetectDirectoryStorageAdapter to load the initial configuration files from the configuration/initial/ folder. These files will be pushed as the initial configuration for the config subsystem. Since this adapter is Read only, it will not store any configuration snapshot during the controller lifecycle.
  • XmlFileStorageAdapter to store snapshots of the current configuration after any change in the file configuration/current/controller.currentconfig.xml (Only 1 snapshot backup is kept; every new change overwrites the previous one).

The initial configuration in the controller distribution consists of 2 files in the xml format:

  • configuration/initial/00-netty.xml:
<snapshot>
    <required-capabilities>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&amp;revision=2013-11-19</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&amp;revision=2013-11-12</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup?module=threadgroup&amp;revision=2013-11-07</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:timer?module=netty-timer&amp;revision=2013-11-19</capability>
    </required-capabilities>
    <configuration>
 
        <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                <module>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup">netty:netty-threadgroup-fixed</type>
                    <name>global-boss-group</name>
                </module>
                <module>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup">netty:netty-threadgroup-fixed</type>
                    <name>global-worker-group</name>
                </module>
                <module>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:timer">netty:netty-hashed-wheel-timer</type>
                    <name>global-timer</name>
                </module>
                <module>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor">netty:netty-global-event-executor</type>
                    <name>global-event-executor</name>
                </module>
            </modules>
 
            <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                <service>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
                    <instance>
                        <name>global-boss-group</name>
                        <provider>/modules/module[type='netty-threadgroup-fixed'][name='global-boss-group']</provider>
                    </instance>
                    <instance>
                        <name>global-worker-group</name>
                        <provider>/modules/module[type='netty-threadgroup-fixed'][name='global-worker-group']</provider>
                    </instance>
                </service>
                <service>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-event-executor</type>
                    <instance>
                        <name>global-event-executor</name>
                        <provider>/modules/module[type='netty-global-event-executor'][name='global-event-executor']</provider>
                    </instance>
                </service>
                <service>
                    <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
                    <instance>
                        <name>global-timer</name>
                        <provider>/modules/module[type='netty-hashed-wheel-timer'][name='global-timer']</provider>
                    </instance>
                </service>
            </services>
        </data>
 
    </configuration>
</snapshot>

This configuration snapshot instantiates netty utilities, which will be utilized by controller components that use netty internally.

  • configuration/initial/01-md-sal.xml:
<snapshot>
 
    <configuration>
 
        <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:schema-service-singleton</type>
                    <name>yang-schema-service</name>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:hash-map-data-store</type>
                    <name>hash-map-data-store</name>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:dom-broker-impl</type>
                    <name>dom-broker</name>
                    <data-store xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">
                        <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-data-store</type>
                        <!-- to switch to the clustered data store, comment out the hash-map-data-store <name> and uncomment the cluster-data-store one -->
                        <name>hash-map-data-store</name>
                        <!-- <name>cluster-data-store</name> -->
                    </data-store>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl</type>
                    <name>binding-broker-impl</name>
                    <notification-service xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
                        <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
                        <name>binding-notification-broker</name>
                    </notification-service>
                    <data-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
                        <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
                        <name>binding-data-broker</name>
                    </data-broker>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:runtime-generated-mapping</type>
                    <name>runtime-mapping-singleton</name>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-notification-broker</type>
                    <name>binding-notification-broker</name>
                </module>
                <module>
                    <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-data-broker</type>
                    <name>binding-data-broker</name>
                    <dom-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
                        <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-broker-osgi-registry</type>
                        <name>dom-broker</name>
                    </dom-broker>
                    <mapping-service xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
                        <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">binding:binding-dom-mapping-service</type>
                        <name>runtime-mapping-singleton</name>
                    </mapping-service>
                </module>
 
            </modules>
 
            <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                	<service>
				<type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:schema-service</type>
				<instance>
					<name>yang-schema-service</name>
					<provider>/modules/module[type='schema-service-singleton'][name='yang-schema-service']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
				<instance>
					<name>binding-notification-broker</name>
					<provider>/modules/module[type='binding-notification-broker'][name='binding-notification-broker']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-data-store</type>
				<instance>
					<name>hash-map-data-store</name>
					<provider>/modules/module[type='hash-map-data-store'][name='hash-map-data-store']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-broker-osgi-registry</type>
				<instance>
					<name>binding-osgi-broker</name>
					<provider>/modules/module[type='binding-broker-impl'][name='binding-broker-impl']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
				<instance>
					<name>binding-rpc-broker</name>
					<provider>/modules/module[type='binding-broker-impl'][name='binding-broker-impl']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:binding-impl="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">binding-impl:binding-dom-mapping-service</type>
				<instance>
					<name>runtime-mapping-singleton</name>
					<provider>/modules/module[type='runtime-generated-mapping'][name='runtime-mapping-singleton']</provider>
				</instance>
			</service>
			<service>
			<type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-broker-osgi-registry</type>
				<instance>
					<name>dom-broker</name>
					<provider>/modules/module[type='dom-broker-impl'][name='dom-broker']</provider>
				</instance>
			</service>
			<service>
				<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
				<instance>
					<name>binding-data-broker</name>
					<provider>/modules/module[type='binding-data-broker'][name='binding-data-broker']</provider>
				</instance>
			</service>
 
            </services>
        </data>
 
    </configuration>
 
    <required-capabilities>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&amp;revision=2013-11-12</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool?module=threadpool&amp;revision=2013-04-09</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&amp;revision=2013-10-28</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom?module=opendaylight-md-sal-dom&amp;revision=2013-10-28</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl?module=opendaylight-sal-binding-broker-impl&amp;revision=2013-10-28</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl?module=opendaylight-sal-dom-broker-impl&amp;revision=2013-10-28</capability>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:common?module=opendaylight-md-sal-common&amp;revision=2013-10-28</capability>
    </required-capabilities>
 
</snapshot>

This configuration snapshot instantiates md-sal modules.

After the controller is started, all these modules will be instantiated and configured. They can be further referenced from the new modules as dependencies, reconfigured, or even deleted. These modules are considered to be the base configuration for controller and the purpose of them being configured automatically is to simplify the process of controller configuration for users, since the base modules will already be ready for use.

Adding custom initial configuration

There are multiple ways to add custom initial confguration to the controller distribution:

  1. Manually create the config file, and put it in the initial configuration folder.
  2. Reconfigure the running controller using the yuma yangcli tool. The XmlFileStorageAdapter adapter will store the current snapshot and on the next startup of controller (assuming it was not rebuilt since), it will load the configuration containing your changes.

Custom initial configuration in bgpcep distribution

The BGPCEP project will serve as an example for adding the custom initial configuration. The bgpcep project contains the custom initial configuration that is based on the initial configuration from the controller. It adds new modules, which depend on MD-SAL and netty modules created with the initial config files of the controller. There are multiple config files in the bgpcep project. Only the 30-programming.xml file located under programming-parent/controller-config project will be described in this chapter. This file contains the configuration for an instance of the instruction-scheduler module:

<?xml version="1.0" encoding="UTF-8"?>
<!-- vi: set et smarttab sw=4 tabstop=4: -->
<!--
      Copyright (c) 2013 Cisco Systems, Inc. and others.  All rights reserved.
 
 This program and the accompanying materials are made available under the
 terms of the Eclipse Public License v1.0 which accompanies this distribution,
 and is available at http://www.eclipse.org/legal/epl-v10.html.
-->
<snapshot>
	<required-capabilities>
		<capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&amp;revision=2013-10-28</capability>
		<capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&amp;revision=2013-11-19</capability>
		<capability>urn:opendaylight:params:xml:ns:yang:controller:programming:impl?module=config-programming-impl&amp;revision=2013-11-15</capability>
		<capability>urn:opendaylight:params:xml:ns:yang:controller:programming:spi?module=config-programming-spi&amp;revision=2013-11-15</capability>
	</required-capabilities>
	<configuration>
 
		<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
				<module>
					<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:programming:impl">prefix:instruction-scheduler-impl</type>
					<name>global-instruction-scheduler</name>
					<data-provider>
						<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
						<name>binding-data-broker</name>
					</data-provider>
					<notification-service>
						<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
						<name>binding-notification-broker</name>
					</notification-service>
					<rpc-registry>
						<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
						<name>binding-rpc-broker</name>
					</rpc-registry>
					<timer>
						<type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
						<name>global-timer</name>
					</timer>
				</module>
			</modules>
 
			<services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
				<service>
					<type xmlns:pgmspi="urn:opendaylight:params:xml:ns:yang:controller:programming:spi">pgmspi:instruction-scheduler</type>
					<instance>
						<name>global-instruction-scheduler</name>
						<provider>/modules/module[type='instruction-scheduler-impl'][name='global-instruction-scheduler']</provider>
					</instance>
				</service>
			</services>
		</data>
 
	</configuration>
</snapshot>


Instruction-scheduler is instantiated as a module of type instruction-scheduler-impl with name global-instruction-scheduler:

<module>
       <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:programming:impl">prefix:instruction-scheduler-impl</type>
       <name>global-instruction-scheduler</name>
       ...


There is also an alias created for this module instancfe and the alias is global-instruction-scheduler of type instruction-scheduler:

...
<service>
	<type xmlns:pgmspi="urn:opendaylight:params:xml:ns:yang:controller:programming:spi">pgmspi:instruction-scheduler</type>
	<instance>
		<name>global-instruction-scheduler</name>
		<provider>/modules/module[type='instruction-scheduler-impl'][name='global-instruction-scheduler']</provider>
	</instance>
</service>
...


The type of the alias is instruction-scheduler. This type refers to a certain service that is implemented by the instruction-scheduler-impl module. With this service type, global-instruction-scheduler instance can be injected into any other module that requires instruction-scheduler as a dependency. One module can provide(implement) multiple services and each of these services can be assigned an alias. This alias can be later used to reference the implementation it is pointing to. If no alias is assigned by the user, a default alias will be assigned for each provided service. the default alias is constructed from the name of the module instance with a prefix ref_ and a possible suffix containing a number to resolve name clashes. It is advised for users to provide aliases for each service of every module instance. And use these aliases for dependency injection. References to the alias global-instruction-scheduler can be found in subsequent config files in the bgpcep project for example, 32-pcep.xml located under the pcep-parent/pcep-controller-config project.


The configuration contains 4 dependencies on MD-SAL and netty modules:

...
<data-provider>
	<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
	<name>binding-data-broker</name>
</data-provider>
<notification-service>
	<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
	<name>binding-notification-broker</name>
</notification-service>
<rpc-registry>
	<type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
	<name>binding-rpc-broker</name>
</rpc-registry>
<timer>
	<type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
	<name>global-timer</name>
</timer>
...

This instruction-scheduler-impl module and its configuration is defined in yang module: config-programming-impl.yang.

MD-SAL dependencies:

  • data-provider dependency
  • notification-service dependency
  • rpc-registry dependency

All MD-SAL dependencies can be found in the MD-SAL initial configuration file for example, rpc-registry dependency points to an alias binding-rpc-broker of the type binding-rpc-registry. This alias further points to an instance of the binding-broker-impl named binding-broker-impl. The Yang module that defines the binding-broker-impl module : opendaylight-binding-broker-impl.yang.

Netty dependencies:

  • timer dependency

This configuration expects these dependencies to be already up and ready. It is the responsibility of the configuration subsystem to find the dependency and inject it. If the configuration of a module points to a non-existing dependency, the configuration subsystem will produce an exception during the validation phase. Every user created configuration needs to point to existing dependencies. 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. This means that every configuration file will have the visibility of modules from all previous configuration files via aliases.


Note: The configuration provided by initial config files can also be pushed to the controller at runtime using netconf client. The whole configuration located under the data tag needs to be inserted into the config tag in the edit-config rpc. For more information, see examples.

Configuration Persister

As a part of the configuration subsystem, the purpose of the persister is to save and load a permanent copy of a configuration. The Persister interface represents basic operations over a storage - persist configuration and load last config, configuration snapshot is represented as string and set of it's capabilities. StorageAdapter represents an adapter interface to the ConfigProvider - subset of BundleContext, allowing access to the OSGi framework system properties.

Persister Implementation

Configuration persister implementation is part of the Controller Netconf. PersisterAggregator class is implemenataion of Presister interface. The functionality is delegated to the storage adapters Storage adapters are low level persisters that do the heavy lifting for this class. Instances of storage adapters can be injected directly via constructor or instantiated from a full name of its class provided in a properties file. There can be many persisters configured, and varying numbers of them can be used.

Example of presisters configuration :

 netconf.config.persister.active=2,3
 # read startup configuration
 netconf.config.persister.1.storageAdapterClass=org.opendaylight.controller.config.persist.storage.directory.xml.XmlDirectoryStorageAdapter
 netconf.config.persister.1.properties.fileStorage=configuration/initial/
 
 netconf.config.persister.2.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.FileStorageAdapter
 netconf.config.persister.2.readonly=true
 netconf.config.persister.2.properties.fileStorage=configuration/current/controller.config.1.txt
 
 netconf.config.persister.3.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.FileStorageAdapter
 netconf.config.persister.3.properties.fileStorage=configuration/current/controller.config.2.txt
 netconf.config.persister.3.properties.numberOfBackups=3

During server startup, ConfigPersisterNotificationHandler requests the last snapshot from the underlying storages. Each storage can respond by giving a snapshot or an absent response. The PersisterAggregator#loadLastConfigs() will search for the first non-absent response from storages ordered backwards as user specified (first '3', then '2'). When a commit notification is received, '2' will be omitted because the read-only flag is set to true, so only '3' will have a chance to persist the new configuration. If read-only was false, or not specified, both storage adapters would be called in the order specified by 'netconf.config.persister' property.

Persister Notification Handler

ConfigPersisterNotificationHandler class is responsible for listening for netconf notifications containing latest committed configuration. The listener can handle incoming notifications, delegates configuration saving/loading to the persister.

Storage Adapter Implementations

XML File Storage

The XmlFileStorageAdapter implementation stores configuration in an xml file.

XML Directory Storage

XmlDirectoryStorageAdapter retrieves the initial configuration from a directory. If multiple xml files are present, files are ordered based on the file names and pushed in this order (for example, 00.xml, then 01.xml..) Each file defines its required capabilities, so it will be pushed when those capabilities are advertized by ODL. Writing to this persister is not supported.

No-Operation Storage

NoOpStorageAdapter serves as a dummy implementation of the storage adapter.

Obsolete storage adapters

File Storage

FileStorageAdapter implements StorageAdapter, and provides file based configuration persisting. File path and name is stored as a property and a number of stored backups, expressing the count of the last configurations to be persisted, too. The implementation can handle persisting input configuration and load the last configuration.

Directory Storage

DirectoryStorageAdapter retrieves initial configurations from a directory. If multiple files are present, snapshot and required capabilities will be merged together. See configuration later on this page for details. Writing to this persister is not supported.

Autodetect Directory Storage

AutodetectDirectoryStorageAdapter retrieves initial configuration from a directory (exactly as Xml Directory Storage) but supports xml as well as plaintext format for configuration files. Xml and plaintext files can be combined in one directory. Purpose of this persister is to keep backwards compatibility for plaintext configuration files.

! Important: This functionality will be removed in releases since Plaintext File/Directory adapters are deprecated, and will be fully replaced by xml storage adapters.

Persisted snapshot format

Configuration snapshots are persisted in xml files for both file and directory adapters. They share the same format:

<snapshot>
    <required-capabilities>
        <capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&amp;revision=2013-11-19</capability>
        ...
    </required-capabilities>
    <configuration>
 
        <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
             ...    
            </modules>
 
            <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
             ...    
            </services>
 
        </data>
 
    </configuration>
</snapshot>

The whole snapshot is encapsulated in the snapshot tag that contains two children elements:

  • The required-capabilities tag contains the list of yang capabilities that are required to push configurations located under the configuration tag. The config persister will not push the configuration before the netconf endpoint for the config subsystem reports all needed capabilities. Every yang model that is referenced within this xml file (as namespace for xml tag) must be referenced as a capability in this list.
  • The configuration tag contains the configurations to be pushed to the config subsystem. It is wrapped in a data tag with the base netconf namespace. The whole data tag, with all its child elements, will be inserted into an edit-config rpc as config tag. For more information about the structure of configuration data, see base yang model for the config subsystem and all the configuration yang files for the controller modules as well as those provided examples. Examples contain multiple explained edit-config rpcs that change the configuration.

Note: Xml File adapter adds additional tags to the xml format since it supports multiple snapshots per file. Xml format for xml file adapter:

<persisted-snapshots>
   <snapshots>
      <snapshot>
         <required-capabilities>
            <capability>urn:opendaylight:params:xml:ns:yang:controller:shutdown:impl?module=shutdown-impl&amp;revision=2013-12-18</capability>
         </required-capabilities>
         <configuration>
            <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
               <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                 ....
               </modules>
               <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                 ...
               </services>
            </data>
         </configuration>
      </snapshot>
      <snapshot>
         <required-capabilities>
            <capability>urn:opendaylight:params:xml:ns:yang:controller:shutdown:impl?module=shutdown-impl&amp;revision=2013-12-18</capability>
         </required-capabilities>
         <configuration>
            <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
               <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                 ....
               </modules>
               <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
                 ...
               </services>
            </data>
         </configuration>
      </snapshot>
   </snapshots>
</persisted-snapshots>