> On May 13, 2016, at 10:29 AM, Tom Pantelis <[email protected]> wrote: > > We can remove corresponding config XML files and remove them from the > features. We can also go a step further and remove the config yang and Module > classes altogether. The only potential issue with this is if an > etc/opendaylight/current/controller.currentconfig.xml exists on upgrade. For > those that aren't aware of this file it is created when a config is pushed > via the restconf controller-config yang-ext:mount loopback (most commonly > when a netconf connector mount is pushed). The CSS merges all config files > under etc/opendaylight/karaf into controller.currentconfig.xml and uses this > file to load configs on restart from then on. Therefore if this file exists > on upgrade, it would contain the XML for the removed config yang files and > would try to push them but fail.
This make complete sense to me, although, and keep me honest, doing so we would slowly wipe out config system injection, right? This is really fine but wrt config system, I though we were keeping both along the way. If indeed wiring through config system is to be removed, then +1 to delete default-config.xml file and the associated yang model. > the XML elements corresponding to the removed yang files would have to be > removed. Maybe we can find a way to script this, to help folks doing upgrade. Then once ODL is blueprint enabled (so probably Carbon), upgrade would be transparent without any action required. Thanks, Alexis
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
