Details
-
Improvement
-
Status: Confirmed
-
Medium
-
Resolution: Unresolved
-
None
-
None
-
None
Description
As raised on https://lists.opendaylight.org/pipermail/mdsal-dev/2018-June/001709.html :
The new ODL "serviceutils" project is hitting a weird issue in the integration/distribution karaf run, which makes me suspect there may be a concurrency related issue in BindingToNormalizedNodeCodec, or code used by it:
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 is seen on https://jenkins.opendaylight.org/releng/job/distribution-check-fluorine/69/consoleFull, but several people have locally done a "mvn clean install" on integration/distribution master, and not been able to locally reproduce above... so it would seem that under some... timing 
condition only hit on the distribution running on Jenkins, the Schema for that RPC interface defined in the new serviceutils/srm/api cannot (yet?) be found.
I've found a few issues from the past which seem possibly related to this:
Attachments
Issue Links
- relates to
-
SRVUTILS-1 rename YANG modules for SRM in serviceutils which are forked from genius to avoid packaging modules with conflicting names
-
- Done
-
