|
Attachment karaf.log has been added with description: Karaf log
|
|
moving to restconf
|
|
Can you elaborate on why this was moved to restconf? Is it incorrectly using ModuleBuilder API?
|
|
Hi Ryan
In actual Restconf code base, RestconfImpl.operationsFromModulesToNormalizedContext() uses old Model API implementation, but in runtime, input parameter passed to this method is obviously implementation of new effective Model API, developed side by side with new statement parser, so that's why we're getting class cast error.
So, it's definitely issue in Restconf code base and I'm working on fix.
Best Regards
Martin
|
|
I posted information about this here:
https://lists.opendaylight.org/pipermail/release/2016-February/005602.html
In essence, we need to figure out if this is actually a blocker for the Beryllium release requiring a respin.
|
|
Thanks for the additional information, Martin. To me this sounds like a blocker.
|
|
From: https://lists.opendaylight.org/pipermail/netconf-dev/2016-February/000265.html
1.) Is this actually blocking? e.g., is there a work-around?
There is no workaround, it is regression from Lithium behaviour. It is less used feature of RESTCONF (not aware of any user inside OpenDaylight),
But since bug was reported externally, seems there are some external users depending on this feature.
We can decrease it to non-blocking but critical, since it is clear regression and should be fixed soon.
2.) When can we expect a fix?
2016-02-17, which is too close to release date, so really considering just RELEASE-NOTEing it.
After analysis of the issue
3.) This was reported on 2/13 and commented on long before midnight UTC yesterday when we did the respin, why didn't anyone engage with the release engineering team before the respin?
At that time we still did not have analysis if this is really blocking issue and regression from Lithium, closer inspection showcased that this bug
is observable all the time thus marking it as Blocking today.
|
|
If the issue is NONBLOCKING and does not require us to delay Beryllium release, can we (1) downgrade the severity of the bug, (2) mark the target as Beryllium-1, and (3) add release notes identifying the issue and any possible workaround if one exists.
|
|
Workaround:
> 3. Do a GET on the get-schema RPC at
>
> /restconf/operations/opendaylight-inventory:nodes/node/controller-config/
> yang-ext:mount/ietf-netconf-monitoring:get-schema
the GET call of RPC is similar as /restconf/operations/opendaylight-inventory:nodes/node/controller-config/yang-ext:mount/
Which returns list of all available RPCs based on schema cvontext.
The functionality to retrieve for all available RPCs is currently blocked.
Similar functionality (discovery of models and thus RPCs) could be achieved by invoking
GET /restconf/operations/opendaylight-inventory:nodes/node/controller-config/yang-ext:mount
(In reply to Kevin Wang from comment #0)
> Created attachment 827 [details]
> Karaf log
>
> In Beryllium, the get-schema RPC call is not working any more. The server
> returns a 500 error saying there is a java type casting issue.
>
> Reproduce:
>
> 1. Grab the latest distribution code and compile it, do a fresh install
> 2. Install the necessary features in karaf:
> feature:install odl-netconf-connector-ssh odl-mdsal-apidocs
>
>
> You will see the following error:
>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;
> charset=ISO-8859-1"/>
> <title>Error 500 Server Error</title>
> </head>
> <body>
> <h2>HTTP ERROR 500</h2>
> <p>Problem accessing
> /restconf/operations/opendaylight-inventory:nodes/node/controller-config/
> yang-ext:mount/ietf-netconf-monitoring:get-schema. Reason:
>
> <pre> Server Error</pre>
> </p>
> <h3>Caused by:</h3>
> <pre>java.lang.ClassCastException:
> org.opendaylight.yangtools.yang.model.util.type.DerivedStringType cannot be
> cast to org.opendaylight.yangtools.yang.model.util.ExtendedType
> at
> org.opendaylight.yangtools.yang.parser.builder.impl.BuilderUtils.
> wrapTypedefs(BuilderUtils.java:793)
> at
> org.opendaylight.yangtools.yang.parser.builder.util.
> AbstractDocumentedDataNodeContainerBuilder.<init>
> (AbstractDocumentedDataNodeContainerBuilder.java:68)
> at
> org.opendaylight.yangtools.yang.parser.builder.impl.ModuleBuilder.<
> init>(ModuleBuilder.java:141)
> at
> org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.
> operationsFromModulesToNormalizedContext(RestconfImpl.java:330)
> at
> org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.
> getOperations(RestconfImpl.java:316)
> at
> org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.
> getOperations(StatisticsRestconfServiceWrapper.java:75)
> at
> org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.
> getOperations(RestconfCompositeWrapper.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
> java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.
> invoke(JavaMethodInvokerFactory.java:60)
> at
> com.sun.jersey.server.impl.model.method.dispatch.
> AbstractResourceMethodDispatchProvider$TypeOutInvoker.
> _dispatch(AbstractResourceMethodDispatchProvider.java:185)
> at
> com.sun.jersey.server.impl.model.method.dispatch.
> ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.
> java:302)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.
> accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.
> accept(ResourceObjectRule.java:100)
> at
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.
> accept(RightHandPathRule.java:147)
> at
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.
> accept(RootResourceClassesRule.java:84)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.
> _handleRequest(WebApplicationImpl.java:1511)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.
> _handleRequest(WebApplicationImpl.java:1442)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.
> handleRequest(WebApplicationImpl.java:1391)
> at
> com.sun.jersey.server.impl.application.WebApplicationImpl.
> handleRequest(WebApplicationImpl.java:1381)
> at
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:
> 416)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.
> service(ServletContainer.java:538)
> at
> com.sun.jersey.spi.container.servlet.ServletContainer.
> service(ServletContainer.java:716)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.
> java:1496)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:
> 247)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:
> 210)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.
> java:1467)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.
> java:1467)
> at
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.
> java:61)
> at
> org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
> at
> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:
> 137)
> at
> org.apache.shiro.web.servlet.OncePerRequestFilter.
> doFilter(OncePerRequestFilter.java:125)
> at
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.
> java:66)
> at
> org.apache.shiro.web.servlet.AbstractShiroFilter.
> executeChain(AbstractShiroFilter.java:449)
> at
> org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.
> java:365)
> at
> org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:
> 90)
> at
> org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:
> 83)
> at
> org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.
> java:383)
> at
> org.apache.shiro.web.servlet.AbstractShiroFilter.
> doFilterInternal(AbstractShiroFilter.java:362)
> at
> org.apache.shiro.web.servlet.OncePerRequestFilter.
> doFilter(OncePerRequestFilter.java:125)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.
> java:1467)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.
> doHandle(HttpServiceServletHandler.java:69)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:
> 231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:
> 1086)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.
> doHandle(HttpServiceContext.java:240)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:
> 193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:
> 1020)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.
> handle(JettyServerHandlerCollection.java:75)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
> 116)
> at org.eclipse.jetty.server.Server.handle(Server.java:370)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.
> handleRequest(AbstractHttpConnection.java:494)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.
> headerComplete(AbstractHttpConnection.java:971)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.
> headerComplete(AbstractHttpConnection.java:1033)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:
> 82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.
> java:696)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.
> java:53)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:
> 608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:
> 543)
> at java.lang.Thread.run(Thread.java:745)
> </pre>
> <hr />
> <i>
> <small>Powered by Jetty://</small>
> </i>
> <br/>
>
>
> </body>
> </html>
>
>
>
>
> Karaf log attached.
|
|
Hi Martin,
I notice it is slotted for Beryllium-SR1, is this still the case? Not trying to be a nuisance or add more work to your plate, I am curious since we are quickly approaching the deadline for SR-1.
Thanks,
Ryan
|
|
Hi Ryan
Solution, I started to implement around time of discovery of this bug, turned out to be wrong way. We need to think about really custom solution for this particular case. Thanks to existence of workaround for this issue, I am working on other various tasks with higher priority, so we might want to postpone this issue for now. Please let me know if you're OK with this status. Thank you.
Best Regards
Martin
|
|
Hi Martin,
Although a workaround does exist, I still think we should prioritize fixing this endpoint. Can you explain a bit further by what you mean by a "custom solution".
This comment:
"RestconfImpl.operationsFromModulesToNormalizedContext() uses old Model API implementation, but in runtime, input parameter passed to this method is obviously implementation of new effective Model API, developed side by side with new statement parser, so that's why we're getting class cast error."
Implies that we should migrate "RestconfImpl.operationsFromModulesToNormalizedContext()" from the old model API to the new model API? After investigating this, do you think this is still the case? Or is there something else lurking here?
Any information you can provide is greatly appreciated!
Thanks,
Ryan
|
|
Hi Ryan
Obviously, this issue is still hot on our plate and certainly not forgotten.
I don't see the solution as a simple migration, but rather custom implementation for this and only particular case. We're currently discussing this issue in dev team in order to deliver as soon as we can for Beryllium. Hope this helps for now and we'll come back to you.
Best Regards
Martin
|
|
Intermediate fix is targeted for Beryllium-1
|
|
fixes pushed:
yangtools:
https://git.opendaylight.org/gerrit/35991
restconf:
https://git.opendaylight.org/gerrit/35992
Note: Beryllium code base only, we need to implement brand new solution for Boron
|
|
Is this fixed in Boron? This is marked as "Resolved Fixed", but it appears that the patches listed below are for Beryllium only?
|
|
Hi Ryan
Because target and solution differs, I will rather open new bug for this issue.
Martin
|
|
Boron tracked here:
https://bugs.opendaylight.org/show_bug.cgi?id=5553
|
Generated at Wed Feb 07 20:14:17 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.
karaf.log