Operating System: All
Platform: All

Attachment karaf.log has been added with description: odl log

Karaf config pusher is different to the basic config pusher. It loads config xml files as a part of a feature.

If you need to change the configuration, you have to wait until controller is up and running and then push the configuration manually using Netconf, Restconf + loopback netconf connector or JMX.

There will be an entry on wiki for how to do that using Restconf + loopback netconf connector in the near future.

So this is not a bug, marking as enhancement.

Work around was to POST XRVR device configuration to configuration datastore

/restconf/config/opendaylight-inventory:nodes/node/controller-config/yang-ext:mount/config:modules

PAYLOAD

<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type>
<name>controller-config_xrvr</name>
<address xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">10.25.2.37</address>
<port xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">830</port>
<username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">cisco</username>
<password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">cisco</password>
<tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only>
<event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type>
<name>global-event-executor</name>
</event-executor>
<binding-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
<name>binding-osgi-broker</name>
</binding-registry>
<dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type>
<name>dom-broker</name>
</dom-registry>
<client-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-client-dispatcher</type>
<name>global-netconf-dispatcher</name>
</client-dispatcher>
<processing-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
<type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</type>
<name>global-netconf-processing-executor</name>
</processing-executor>
</module>

Promised wiki entry for workaround:

https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_additional_netconf_connector_while_controller_is_running

We need enhance karaf config pusher to allow pushing initial config files from pure xml files. Not just within features. Since it is then impossible to easily modify/add initial config files.

(In reply to Maros Marsalek from comment #4)
> We need enhance karaf config pusher to allow pushing initial config files
> from pure xml files. Not just within features. Since it is then impossible
> to easily modify/add initial config files.

It was also my initial reaction, but then I have heard counter arguments.

Usual way for pushing additional config files was unconditional, which means it was possible to push xml file before its handling feature has been installed. This can lead to confusing errors, missing functionality, and it has great (non-deterministic) chance to happen when karaf is being re-started.

As opposed to that, adding or modifying feature-defined configs is relatively painless.
To modify, simply place your modified file (without filename change) to etc/opendaylight/karaf/ before feature is installed, it will be applied instead of the packaged "default" config file.
To add, you can use the fact that if a feature can digest config, it usually has default one packaged; so you only need to merge your additions to the default, and do just described "modify" steps.
For netconf-connector, it means merging additional sal-netconf-connector modules into 99-netconf-connector.xml file.

Changing this to new feature.

You are right Vratko. With karaf it is possible that required bundles will not appear at all if user does not install needed features. But this problem was also present with the old distribution and config pusher tries to wait for the bundles to appear (using required capabilities tag in the xml files). The case was an unresolved bundle or unknown required capabilities stated in the config file. With detailed error reporting or some kind of "auto install feature" mechanism this might be feasible, but a broader discussion is welcomed.

Move to NETCONF project

Config Subsystem is gone, this is no longer relevant.