Operating System: All
Platform: All

A model was included in the required-capabilities section of a default-config.xml where the namespace was wrong. The SFT passed, but when loading with karaf it fails with the below:

Unable to push configuration due to missing yang models. Yang models that are missing, but required by the configuration: [urn:opendaylight:genius:interfacemgr?module=odl-interface&revision=2016-04-06]

[1] is the patch where the wrong namespace is included. the value interfacemgr should have been interfacemanager. That model is from another project. The value used to be interfacemgr, but was changed to interfacemanager some time back. [2] was pushed to fix the issue.

[1] https://git.opendaylight.org/gerrit/#/c/43145/2/vpnservice/dhcpservice/dhcpservice-impl/src/main/config/default-config.xml

[2] https://git.opendaylight.org/gerrit/43230

This is a problem of packaging-versus-runtime. Packaging is correct, as all required artifacts were present – which is really what SFT checks: all the bundles started successfully.

Based on artifact dependency tree, SFT cannot be made cognizant of controller's config subsystem. That also means the problem should be fixed on the controller side – somehow.

I think this could be fixed in CSS by having a bundle, which would only start successfully once the initial configuration has been pushed successfully – e.g. integrate with ConfigPusherImpl. The CSS would declare the bundle in its features, and it can fail to activate after some time – thus forcing SFT (if it waits for all bundles to start). There may be a problem if karaf waits for the start before starting downstream features...

As a workaround, distribution-check job installs odl-integration-all feature and then greps karaf.log for known failures. So if the configfile in question is pulled by odl-integration-all, semantic errors will fail the distribution-check job.

An example of distribution-check job detecting such an error: https://git.opendaylight.org/gerrit/#/c/47879/1
An example of the job passing, because the affected feature is not included in integration:
https://git.opendaylight.org/gerrit/47890

> really what SFT checks: all the bundles started successfully

actually SFT up to 2 days ago only checked that feature:install worked (e.g. no bad feature names), it didn't used to fully check that all the bundles really started successfully so far; but https://lists.opendaylight.org/pipermail/dev/2017-January/003106.html introduced that now (2 days ago).

Now it checks both that all bundles are able to resolve, start AND that their Blueprint wiring managed to resolve.

What's missing is checking that controller's config subsystem (CSS) managed to fully resolve - just like I've done for Blueprint (actually I haven't "done" much, but I've found a Karaf API for this).

I'm not sure if it's worth investing further in the controller's config subsystem (CSS), given that we're increasingly migrating everything off it and to BP, but if someone would like to, and know how to query CSS if it has "fully resolved", then that could be added; either directly in the (new) BundleDiagInfos utility (but the problem would be that odlparent can't depend on controller..), or by controller somehow exposing it to Karaf's BundleService, like Blueprint does (I'm assuming is extensible; it would need a bit more digging).

> missing is checking that controller's config subsystem (CSS)

If someone ever does want to extend the SFT for this, I believe the code in netvirt statemanager's ConfigStateManager class removed in https://git.opendaylight.org/gerrit/#/c/54387/ may be of interest how to do this.

Config Subsystem is gone, we have proper Blueprint/SCR integration, hence this works now.