On Sun, Sep 23, 2018 at 11:34 AM Michael Vorburger <vorbur...@redhat.com> wrote:
> On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis <tompante...@gmail.com> > wrote: > >> On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger <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. > > 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. > > Yours sincerely, >>> M. for the ODL Bot <https://github.com/vorburger/opendaylight-bot> >>> >>> >>> https://git.opendaylight.org/gerrit/#/q/topic:neon-mri >>> >>> >>> https://jenkins.opendaylight.org/releng/view/integration/job/integration-multipatch-test-neon/26/console >>> >>> _______________________________________________ >>> controller-dev mailing list >>> controller-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> >>
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
