On 23/09/2018 17:33, Michael Vorburger wrote: > On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis <tompante...@gmail.com > <mailto:tompante...@gmail.com>> wrote: > > On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger > <vorbur...@redhat.com <mailto:vorbur...@redhat.com>> 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.
Done. > 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 > 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 :) Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
