Operating System: All
Platform: All

With additional diagnostics in blueprint, odl-mdsal-broker-local boils down to:

Tests in error:
Condition with alias 'checkBundleDiagInfos' didn't complete within 5 minutes because lambda expression in org.opendaylight.odlparent.bundlestest.TestBundleDiag: expected system either ready with all bundles Active, or Stopping or Failure (but not still booting in GracePeriod, Waiting, Starting, Unknown;but just Resolved and some exceptional Installed OK) but was <diag: Booting

1. NOK org.opendaylight.mdsal.eos-binding-adapter: OSGi state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
1/20/17 12:32 AM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer) (objectClass=org.opendaylight.mdsal.eos.dom.api.DOMEntityOwnershipService)

2. NOK org.opendaylight.mdsal.singleton-dom-impl: OSGi state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
1/20/17 12:32 AM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.eos.dom.api.DOMEntityOwnershipService)

3. NOK org.opendaylight.controller.sal-broker-impl: OSGi state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
1/20/17 12:32 AM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.eos.dom.api.DOMEntityOwnershipService) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMDataBroker)

4. NOK org.opendaylight.controller.sal-binding-broker-impl: OSGi state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
1/20/17 12:32 AM
Missing dependencies:
(objectClass=org.opendaylight.controller.md.sal.dom.spi.DOMNotificationSubscriptionListenerRegistry) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMMountPointService) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMNotificationPublishService) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMDataBroker) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMDataBroker) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMRpcProviderService) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMRpcService) (objectClass=org.opendaylight.controller.md.sal.dom.api.DOMNotificationService)

FTR: The just fixed CONTROLLER-1586 helps, a lot, to better understand the root cause of the DOMRpcService related failure shown above. I'd recommend to re-run SFT on the features above, now that CONTROLLER-1586 has gone in, to get a clearer log.

To solve the odl-mdsal-broker-local problem, we need a single-node EOS implementation (to be provided by mdsal project).

We then need to refactor the feature layout so that 'odl-mdsal-broker-local' is not pulled in into 'odl-mdsal-broker'. The common bits between the two should be part of 'odl-mdsal-broker-base' feature.

Is there still an issue here? If so does it need to be a blocker?

> Is there still an issue here?

The 4 features (above) are currently (master) still listed in (both Karaf 3 & 4's) SingleFeatureTest BLACKLISTED_BROKEN_FEATURES, so this issue is not "done".. and should not be closed until those can and have been removed.

.. but Robert seems to have done some work re. his comment in above in MDSAL-226 <https://git.opendaylight.org/gerrit/#/c/50749/> - Robert, does that work mean what you said above is fully done and we can remove all 4 blacklist features from SFT?

If you like I could just re-tested this (uncomment it and see) ?

> If so does it need to be a blocker?

that depends essentially on whether we consider the overall ODLPARENT-58 which this one blocks as a Blocker for the next release. My view is that it is and that it would be good to sort this out cleanly, thus ensuring that ALL ODL features we ship actually do work when you install them.

Cool. I was just wondering if this bug is stale, i.e. was actually resolved but was inadvertently left open. But that isn't the case...

(In reply to Michael Vorburger from comment #5)
> > Is there still an issue here?
>
> The 4 features (above) are currently (master) still listed in (both Karaf 3
> & 4's) SingleFeatureTest BLACKLISTED_BROKEN_FEATURES, so this issue is not
> "done".. and should not be closed until those can and have been removed.
>
> .. but Robert seems to have done some work re. his comment in above in bug
> 7611 <https://git.opendaylight.org/gerrit/#/c/50749/> - Robert, does that
> work mean what you said above is fully done and we can remove all 4
> blacklist features from SFT?
>
> If you like I could just re-tested this (uncomment it and see) ?
>
> > If so does it need to be a blocker?
>
> that depends essentially on whether we consider the overall ODLPARENT-58 which
> this one blocks as a Blocker for the next release. My view is that it is
> and that it would be good to sort this out cleanly, thus ensuring that ALL
> ODL features we ship actually do work when you install them.

The Carbon Blocker police are getting after me. Is this still an issue and, if so, does it need to be a blocker?

Downgraded importance from critical to major, in line with the importance assigned to the "parent issue" blocks ODLPARENT-58 which this was originally created for, and same as the similar issues linked as depends on in ODLPARENT-58 in other projects.

This bug was last updated over a year ago so I'm assuming it's no longer an issue so closing it.

This actually is not fixed.

Most of the work is done – the only thing remaining is the local DataBroker activator in odl-mdsal-broker-local.

Then again, this really should be called odl-controller-broker-local, and local datastore should be provided by MD-SAL in odl-mdsal-broker-local – following both namespace assignments and logic.

Since controller is providing only CDS and legacy APIs, users should be okay with depending only on odl-mdsal-broker-local as long they don't require CDS or legacy APIs.

I have just enabled single feature test: https://git.opendaylight.org/gerrit/c/controller/+/95410 and it pass.

I think that mdsal-eos-dom-simple activation was fixed in: https://git.opendaylight.org/gerrit/c/mdsal/+/81932