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

2018-09-23 Thread Michael Vorburger 
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 http://opendaylight.org/xmlns/blueprint/v1.0.0))
>.

Yours sincerely,
M. for the ODL 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

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

2018-09-23 Thread Tom Pantelis 
On Sun, Sep 23, 2018 at 7:26 AM Michael 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  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.


>
> Yours sincerely,
> M. for the ODL 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

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

2018-09-23 Thread Michael Vorburger 
On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis  wrote:

> On Sun, Sep 23, 2018 at 7:26 AM Michael 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 > 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
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 ?

Yours sincerely,
>> M. for the ODL 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

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

2018-09-23 Thread Tom Pantelis 
On Sun, Sep 23, 2018 at 11:34 AM Michael Vorburger 
wrote:

> On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis 
> wrote:
>
>> On Sun, Sep 23, 2018 at 7:26 AM Michael 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 >> 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 rem

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

2018-09-23 Thread Robert Varga 
On 23/09/2018 17:33, Michael Vorburger wrote:
> On Sun, Sep 23, 2018 at 3:21 PM Tom Pantelis  > wrote:
> 
> On Sun, Sep 23, 2018 at 7:26 AM Michael Vorburger
> 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  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