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

Robert Varga

On 23/09/2018 17:33, Michael Vorburger wrote:
On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis <tompantelis@...
<mailto:tompantelis@...>> wrote:

On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger
<vorburger@... <mailto: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

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
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
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}
state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
9/23/18 10:55 AM
Missing dependencies: 

This is b/c 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
...) 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
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 ?
Tom's email has the details. Yes, we want a new feature, no
odl-mdsal-broker-local is an overkill, yes, we want to move the
blueprints (because that change is good), no we do not need to do in in
the MRI window :)


Join to automatically receive all group messages.