Hi,
   The issue cannot be reproduced locally, even when I try to install 
odl-integration-all from distribution.
   But whenever I download the distribution built on Jenkins[0]  from my patch 
to enable serviceutils in distribution, the feature:install fails with the same 
error as below.
Thanks,
Faseela

[0] 
https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/integration/distribution/opendaylight/0.9.0-SNAPSHOT/opendaylight-0.9.0-20180621.134056-7.zip

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, June 21, 2018 6:56 PM
To: controller-dev <controller-dev@lists.opendaylight.org>; 
mdsal-...@lists.opendaylight.org
Cc: Stephen Kitt <sk...@redhat.com>; serviceutils-...@lists.opendaylight.org; 
Vishal Thapar <vtha...@redhat.com>; Faseela K <faseel...@ericsson.com>
Subject: Re: Serviceutils distro failure

On Thu, Jun 21, 2018 at 1:41 PM, Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote:
+controller-dev & mdsal-dev:

On Thu, Jun 21, 2018 at 4:57 AM, Vishal Thapar 
<vtha...@redhat.com<mailto: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-check-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 Services

Blueprint

6/20/18 6:35 PM

Exception:

Unable to initialize bean .component-2

org.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<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode | 
~ = http://vorburger.ch
<http://vorburger.ch/>

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to