yeah - saw that too:
2017-05-01 10:44:13,976 | ERROR | rint Extender: 1 |
BlueprintContainerImpl | 12 -
org.apache.aries.blueprint.core - 1.7.1 | Unable to start blueprint
container for bundle
org.opendaylight.controller.sal-binding-broker-impl/1.5.0.Carbon due
to unresolved dependencies
[(objectClass=org.opendaylight.mdsal.binding.generator.api.ClassLoadingStrategy)]
java.util.concurrent.TimeoutException
at
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)[12:org.apache.aries.blueprint.core:1.7.1]
On Mon, May 1, 2017 at 4:11 PM, Colin Dixon <co...@colindixon.com> wrote:
> It seems like there's something wrong with who sal-binding-broker-impl
> comes up and doesn't get the ClassLoadingStrategy and then SFT hangs. So
> far, thats' the first exception that happens in every SFT hang I've looked
> into.
>
> Robert, TomP, any ideas what would cause this. It looks like the AAA issue
> we were having before, but it's not AAA.
>
> --Colin
>
>
> On Mon, May 1, 2017 at 4:03 PM, Colin Dixon <co...@colindixon.com> wrote:
>
>> So, Luis told me to go look at the surefire results for some of the SFT
>> failures and I'm finding things like this:
>>
>> = failnever job #4 =
>> relevant logfile: https://logs.opendaylight.org/
>> releng/jenkins092/autorelease-release-failnever-carbon/4/arc
>> hives/nemo/nemo-features/odl-nemo-openflow-renderer/target/
>> surefire-reports/org.opendaylight.odlparent.featuretest.
>> SingleFeatureTest-output.txt.gz
>> Job: https://jenkins.opendaylight.org/releng/view/autorelease/job
>> /autorelease-release-failnever-carbon/4/
>> == Key lines ==
>> 2017-05-01 10:44:22,047 | ERROR | rint Extender: 2 |
>> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core
>> - 1.7.1 | Unable to start blueprint container for bundle
>> org.opendaylight.aaa.shiro/0.5.0.Carbon due to unresolved dependencies
>> [(objectClass=org.opendaylight.controller.md.sal.binding.api.DataBroker),
>> (objectClass=org.opendaylight.aaa.cert.api.ICertificateManager)]
>> java.util.concurrent.TimeoutException
>>
>> = autorelease-carbon job #271 =
>> relevant logfile: https://logs.opendaylight.org/releng/jenkins092/
>> autorelease-release-carbon/285/archives/bgpcep/programming/impl/target/
>> surefire-reports/
>> job: https://jenkins.opendaylight.org/releng/view/autoreleas
>> e/job/autorelease-release-carbon/271/
>> 2017-04-25 16:04:47,169 | ERROR | rint Extender: 2 |
>> BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core
>> - 1.7.1 | Unable to start blueprint container for bundle
>> org.opendaylight.controller.sal-binding-broker-impl/1.5.0.Carbon due to
>> unresolved dependencies [(objectClass=org.opendaylight
>> .mdsal.binding.generator.api.ClassLoadingStrategy)]
>> java.util.concurrent.TimeoutException
>>
>> This looks like the AAA issue that we supposedly fixed. However it's
>> still cropping up in runs as recently as today.
>>
>> --Colin
>>
>>
>>
>>
>> On Mon, May 1, 2017 at 12:45 PM, Colin Dixon <co...@colindixon.com>
>> wrote:
>>
>>> As a random idea, to counteract these failures, would it be a truly
>>> terrible idea to add all the SingleFeaturesTests to the excludes list for
>>> autorelease at least for now?
>>>
>>> --Colin
>>>
>>>
>>> On Mon, May 1, 2017 at 11:18 AM, Colin Dixon <co...@colindixon.com>
>>> wrote:
>>>
>>>> add:
>>>> * SFT for OpenDaylight :: NEMO :: OpenFlow Renderer in failnever job #4
>>>>
>>>> --Colin
>>>>
>>>>
>>>> On Mon, May 1, 2017 at 9:58 AM, Colin Dixon <co...@colindixon.com>
>>>> wrote:
>>>>
>>>>> As I'm tracking autorelease failures here:
>>>>> https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspH
>>>>> BNxKI_9XugJp-6Qbbw20Omk/edit#gid=1455372448
>>>>>
>>>>> I'm noticing a reasonable number of hangs in SFT. Is that to be
>>>>> expected? Is there something we can do about it?
>>>>>
>>>>> Examples
>>>>> * SFT for integration features-test in autorelease-carbon job #271
>>>>> * SFT for netconf SSH server in the failnever job #1
>>>>> * SFT for features4-alto in the failnever job #3
>>>>>
>>>>> Thanks,
>>>>> --Colin
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
