Re: [controller-dev] aaa build failure in proposed topic:neon-mri ("Weather Item" TSC-132)


Tom Pantelis
 



On Sun, Sep 23, 2018 at 11:34 AM Michael Vorburger <vorburger@...> wrote:
On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis <tompantelis@...> wrote:
On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger <vorburger@...> wrote:
Dear maintainers of project aaa,

While verifying the proposed cross-projects changes on managed topic:neon-mri together, your project failed to build; please see https://jenkins.opendaylight.org/releng/view/integration/job/integration-multipatch-test-neon/26/console.

IMHO this is blocking topic:neon-mri / TSC-132 and one of us should see how we can sort this out:

Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 315.015 sec <<< FAILURE! - in org.opendaylight.odlparent.featuretest.SingleFeatureTest
installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: file:/w/workspace/integration-multipatch-test-neon/patch_tester/aaa/features/odl-aaa-password-service/target/feature/feature.xml, Feature: odl-aaa-password-service 0.9.0.SNAPSHOT]  Time elapsed: 314.722 sec  <<< ERROR!
org.awaitility.core.ConditionTimeoutException: Condition with alias 'checkBundleDiagInfos' didn't complete within 300 seconds because lambda expression in org.opendaylight.odlparent.bundlestest.lib.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 {Installed=0, Resolved=5, Unknown=0, GracePeriod=1, Waiting=0, Starting=0, Active=101, Stopping=0, Failure=0}
1. NOK org.opendaylight.aaa.password-service-impl:0.9.0.SNAPSHOT: OSGi state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
9/23/18 10:55 AM
Missing dependencies: 
(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://opendaylight.org/xmlns/blueprint/v1.0.0)) 
>.

This is b/c https://git.opendaylight.org/gerrit/#/c/74964/ moved the aaa-password-service BP xml file under OSGI-INF/blueprint. However the feature does not pull in the ODL blueprint bundles, either directly or indirectly via odl-mdsal-broker-local. 
So it either needs to pull in odl-mdsal-broker-local or we create a feature for the ODL blueprint bundle. For the short-term, that patch doesn't need to
move  the BP xml file for the MRI version bumps so we could put it back under org/opendaylight/blueprint for now and address it in another patch.

I see. For the very short-term and to unblock topic:neon-mri (I'm curious to see how far we can get the multipatch job to progress by all working together this week!) I agree and too would go for the latter and leave them in org/opendaylight/blueprint instead of moving them to OSGI-INF/blueprint in c/74964 (NB not just password-service-blueprint.xml but all BP XML).

Robert, as the author of c/74964 would you like to amend it to do so? If you don't have time but confirm that you agree this is what should be done, then I'm happy to do this as well, in order to unblock.
 
But given that we want to converge on OSGI-INF/blueprint (and explicitly ask projects in the migration documentation on https://wiki.opendaylight.org/view/Neon_platform_upgrade#Blueprint_declarations ...) I think it would be useful to do this uniformely soon-ish, so let's make a plan for that as well, in parallel to fixing the short term?

I started that a while ago in mdsal https://git.opendaylight.org/gerrit/#/c/75528/. But it needed odlparent 4.0.0 to remove the Import{Export}-Service headers. I also have a controller draft patch to follow. However that is running into the same issue with the missing ODL BP NamespaceHandler. It's interesting that we didn't see an issue before with the files under org/opendaylight/blueprint b/c there was no BP extender triggered to try to load them, which wasn't good b/c we weren't actually testing the BP wiring during SFT.
 
I should be easy enough to raise a change in controller to have a new odl-blueprint feature if that's what we want (and I'm happy to), but... do we really want to? Would you then want to add that explicitly to odl-aaa-password-service, and elsewhere where we hit this problem? I don't really understand how it's possible for a bundle to use ODL extensions in its BP XML yet not already depend on the feature that currently brings it along (odl-mdsal-broker-local, from wha you write) - what am I missing? You wouldn't want to just make odl-aaa-password-service dependant on odl-mdsal-broker-local ?

We're going to have to separate the ODL blueprint bundle to it's own feature and move it out of the controller so mdsal can use it - either it's own project or move it into mdsal. But first, in the ODL blueprint bundle, we need to remove the dependencies on the controller APIs. 
 

Join z.archive.aaa-dev@lists.opendaylight.org to automatically receive all group messages.