Hello, As discussed on the Mon call I am in the process of converting the OF plugin bundles to use blueprint. Most of the modules/applications do not provide OSGi services that can be consumed by other bundles. The Module createInstance method becomes a no-op as the wiring is done via blueprint.
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. So if we want to fully support backwards compatibility we would keep the config yang files for however long. Otherwise, on upgrade, the XML elements corresponding to the removed yang files would have to be removed. I think this is a reasonable workaround b/c, in my experience, the controller.currentconfig.xml usually has to modified (or removed) anyway to pickup necessary wiring changes to the XML modules in the new release (hence one of the reasons to convert to blueprint). We don't want to keep these yang files around forever so I propose we bite the bullet now and remove them and probably document the one-time work-around in the release notes. Tom
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
