On Thu, Jun 21, 2018 at 1:41 PM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> +controller-dev & mdsal-dev:
>
> On Thu, Jun 21, 2018 at 4:57 AM, Vishal Thapar <vtha...@redhat.com> wrote:
>
>> Hi Michael, Stephen,
>>
>> We are unable to enable serviceutils in distro due to failure in distro
>> job. I tried looking at logs, it shows something wrong with srm-shell, but
>> it works locally, even with clean m2, so not sure what are we missing. Any
>> inputs?
>>
>> *18:40:41* 2018-06-20T18:40:23,484 | ERROR | Blueprint Extender: 3 | 
>> BlueprintContainerImpl           | 82 - org.apache.aries.blueprint.core - 
>> 1.8.3 | Unable to start blueprint container for bundle 
>> org.opendaylight.serviceutils.srm-shell/0.2.0.SNAPSHOT due to unresolved 
>> dependencies 
>> [(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.dom.api.DOMSchemaService))]
>>
>>
>> https://jenkins.opendaylight.org/releng/job/distribution-che
>> ck-fluorine/69/consoleFull
>>
>
> For background, this is with https://git.opendaylight.
> org/gerrit/#/c/73212/, currently reverted on master.
>
> It passes locally (I just tried), so I suspect another timing related
> issue - somehow the build in distribution is too slow perhaps.
>

I had to refresh my own memory by looking at the code in
odlparent:bundles-test-lib and infrautils:ready, so just as a refresher:
This isn't actually "timing out", in this case. I was wrong to suggest that
"somehow the build in distribution is too slow perhaps" - there are no
timeouts to increase to get this to pass. It's *NOT* waiting those
hard-coded max. 5 minutes. What's happening here is that one of the bundles
is in "bundleState = Failure" (grep that log for that), and that fairly
quickly and early on - there are only 17s between the following two key log
messages:

2018-06-20T18:35:25,908 | INFO  | awaitility[checkBundleDiagInfos] |
SystemReadyImpl                  | 350 -
org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT |
checkBundleDiagInfos: Elapsed time 2s, remaining time 297s, diag: Booting
{Installed=0, Resolved=4, Unknown=0, GracePeriod=117, Waiting=0,
Starting=0, Active=485, Stopping=0, Failure=0}

2018-06-20T18:35:42,573 | ERROR | SystemReadyService-0 | SystemReadyImpl
              | 350 - org.opendaylight.infrautils.ready-impl -
1.4.0.SNAPSHOT | Failed, some bundles did not start (SystemReadyListeners
are not called)
org.opendaylight.odlparent.bundlestest.lib.SystemStateFailureException:
diag failed; some bundles failed to start
diag: Failure {Installed=0, Resolved=4, Unknown=0, GracePeriod=54,
Waiting=0, Starting=0, Active=547, Stopping=0, Failure=1}

The bundle that fails is in Blueprint initialization is the (new)
serviceutils:srm-impl, due to that weird schema not found - so figuring
that one really is the key to resolving this.

Nothing new - just reconfirming previous message, after having stared more
at the logs.

Tom or Robert, if you can help clarify how these schema are normally found
by the BindingToNormalizedNodeCodec, and what could cause one to not be
found, that we interesting... ;-) otherwise I guess we can have some fun
for the next weeks to learn more about this controller and mdsal code!

The error shown about (unresolved dependencies ... DOMSchemaService) is
> probably just an effect, not a cause. This which appears earlier in that
> https://jenkins.opendaylight.org/releng/job/distribution-
> check-fluorine/69/consoleFull log seems to be more interesting:
>
> 2018-06-20T18:35:42,573 | ERROR | SystemReadyService-0 | TestBundleDiag       
>             | 350 - org.opendaylight.infrautils.ready-impl - 1.4.0.SNAPSHOT | 
> NOK org.opendaylight.serviceutils.srm-impl:0.2.0.SNAPSHOT: OSGi state = 
> Active, Karaf bundleState = Failure, due to: Declarative 
> ServicesBlueprint6/20/18 6:35 PMException: Unable to initialize bean 
> .component-2org.osgi.service.blueprint.container.ComponentDefinitionException:
>  Unable to initialize bean .component-2       at 
> org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
>
> (...)
> Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: 
> Error processing "rpc-implementation" for class 
> org.opendaylight.serviceutils.srm.impl.SrmRpcProvider   at 
> org.opendaylight.controller.blueprint.ext.RpcImplementationBean.init(RpcImplementationBean.java:69)
>
> (...)
>
> Caused by: java.lang.IllegalStateException: Schema for interface
> org.opendaylight.yang.gen.v1.urn.opendaylight.serviceutils.
> srm.rpcs.rev170711.SrmRpcsService is not available. at
> com.google.common.base.Preconditions.checkState(Preconditions.java:585) at
> org.opendaylight.mdsal.binding.dom.adapter.BindingToNormalizedNodeCodec.
> getModuleBlocking(BindingToNormalizedNodeCodec.java:303)
>
>
> This doesn't look great, right? How can a Schema for a generated code
> interface just be missing like this? But only in distribution, and not
> locally reproducible?
>
> There is also an occurrence of https://jira.opendaylight.
> org/browse/NETCONF-534 - not sure how worrying that should be?
>
> I've looked for (bundle / feature) "reload" in that log, but can't spot
> anything (but could be missing it).
>
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
>
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to