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

> On Thu, Jun 21, 2018 at 6:32 PM, Vishal Thapar <vtha...@redhat.com> wrote:
>
>> Hi Michael,
>>
>> I was able to reproduce in my local distro build,
>>
>
> Cool! Can you describe the exact steps one has to take? Like literally
> "for dummies", describe for any interested in locally reproducing this
> exactly what you did... ;-)
>
>
​1. build distribution and run karaf.
2.
 feature:repo-add
mvn:org.opendaylight.integration/odl-integration-all/0.9.0-SNAPSHOT/xml/features
3. feature:install odl-integration-all​

​
I may be missing 'git pull' to get latest distribution though.​

so let me know what logging to enable, I can take a shot.
>>
>
> If you could locally "mvn clean install" rebuild with the patches from
> https://git.opendaylight.org/gerrit/#/q/topic:MDSAL-354, and share a new
> log which includes that - that would be very intersting! (There will be
> [probably MUCH] more after that "IllegalStateException: Schema for
> interface org.opendaylight.yang.gen.v1.urn.opendaylight.serviceutils.
> srm.rpcs.rev170711.SrmRpcsService is not available." )
>
>

​If I manage to stay awake after dinner. At least will fire off a build
before going to bed.
​

> http://paste.openstack.org/show/i0tBL9XMbgob0iqPkQvd/
>>
>
> right; that's exactly the same as originally, below.
>
>
>> Regards,
>> Vishal.
>>
>> On Thu, Jun 21, 2018 at 9:32 PM, Michael Vorburger <vorbur...@redhat.com>
>> wrote:
>>
>>> On Thu, Jun 21, 2018 at 5:42 PM, Faseela K <faseel...@ericsson.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> OK but so if it's only possible to reproduce this locally with a binary
>>> blob that we cannot trust on how it was actually built (which is quite
>>> concerning!), and if I understand correctly what you are saying we cannot
>>> reproduce this in a local bulid where we could include logging / debug
>>> patches, then as a next step I would suggest we wait for the additional
>>> logging I've just proposed via https://git.opendaylight.org/g
>>> errit/#/q/topic:MDSAL-354 to be merged to master, and then reproduce
>>> this on a new distribution job run including those patches, and look at
>>> those logs and take it from there. Sounds like a plan?
>>>
>>>
>>>> Thanks,
>>>>
>>>> Faseela
>>>>
>>>>
>>>>
>>>> [0] https://nexus.opendaylight.org/content/repositories/opendayl
>>>> ight.snapshot/org/opendaylight/integration/integration/distr
>>>> ibution/opendaylight/0.9.0-SNAPSHOT/opendaylight-0.9.0-20180
>>>> 621.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-dev@lists.openday
>>>> light.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> 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-che
>>>> ck-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.o
>>>> rg/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