[NETCONF-703] Apidocs does not work in Aluminum Created: 19/Jun/20  Updated: 14/Jul/20  Resolved: 26/Jun/20

Status: Verified
Project: netconf
Component/s: restconf-nb
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: High
Reporter: Luis Gomez Assignee: Ilya Igushev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by NETCONF-685 Apidoc explorer is not able to list m... Resolved
Relates
relates to YANGTOOLS-551 yang-model-util: Cross-reference cons... Confirmed

 Description   

This can be tracked in this CSIT job:
https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-userfeatures-all-aluminium/

When controller just installs RESTCONF, the new apidocs work fine. However when all compatible features are installed, it produces this exception:

javax.servlet.ServletException: javax.servlet.ServletException: java.lang.NumberFormatException: For input string: "0xfff8"
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:88) ~[?:?]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.server.Server.handle(Server.java:500) ~[bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386) ~[bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562) ~[bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) [bundleFile:9.4.22.v20191022]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) [bundleFile:9.4.22.v20191022]
	at java.lang.Thread.run(Thread.java:834) [?:?]

To reproduce:

1) Install aluminium karaf and do:
feature:repo-add mvn:org.opendaylight.integration/features-test/0.13.0-SNAPSHOT/xml/features
feature:install odl-integration-compatible-with-all

2) Open URL: http://10.1.68.201:8181/apidoc/openapi3/18/apis/single

 Comments   
Comment by Robert Varga [ 23/Jun/20 ] 
Caused by: java.lang.NumberFormatException: For input string: "0xfff8"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?]
	at java.lang.Long.parseLong(Long.java:692) ~[?:?]
	at java.lang.Long.valueOf(Long.java:1144) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processTypeDef(DefinitionGenerator.java:716) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processLeafNode(DefinitionGenerator.java:622) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:478) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChoiceNode(DefinitionGenerator.java:563) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:500) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:488) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChoiceNode(DefinitionGenerator.java:563) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:500) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:488) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:488) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processDataNodeContainer(DefinitionGenerator.java:377) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processChildren(DefinitionGenerator.java:488) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processOperationInputOutput(DefinitionGenerator.java:282) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processOperations(DefinitionGenerator.java:270) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.processRPCs(DefinitionGenerator.java:259) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.convertToJsonSchema(DefinitionGenerator.java:149) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.DefinitionGenerator.convertToJsonSchema(DefinitionGenerator.java:166) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.BaseYangSwaggerGenerator.getSwaggerDocSpec(BaseYangSwaggerGenerator.java:309) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.BaseYangSwaggerGenerator.fillDoc(BaseYangSwaggerGenerator.java:195) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.BaseYangSwaggerGenerator.getAllModulesDoc(BaseYangSwaggerGenerator.java:174) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.BaseYangSwaggerGenerator.getAllModulesDoc(BaseYangSwaggerGenerator.java:154) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.AllModulesDocGenerator.getAllModulesDoc(AllModulesDocGenerator.java:34) ~[?:?]
	at org.opendaylight.netconf.sal.rest.doc.impl.ApiDocServiceImpl.getAllModulesDoc(ApiDocServiceImpl.java:67) ~[?:?]
Comment by Robert Varga [ 23/Jun/20 ]

Which boils down to:

 

./openflowplugin/extension/openflowjava-extension-nicira/src/main/yang/nicira-action.yang-144-            leaf in-port {
./openflowplugin/extension/openflowjava-extension-nicira/src/main/yang/nicira-action.yang-145-                type uint16;
./openflowplugin/extension/openflowjava-extension-nicira/src/main/yang/nicira-action.yang:146:                default 0xfff8; // OFPP_INPORT
./openflowplugin/extension/openflowjava-extension-nicira/src/main/yang/nicira-action.yang-147-            }

./openflowplugin/extension/openflowplugin-extension-nicira/src/main/yang/openflowplugin-extension-nicira-action.yang-427-            leaf in-port {
./openflowplugin/extension/openflowplugin-extension-nicira/src/main/yang/openflowplugin-extension-nicira-action.yang-428-                type uint16;
./openflowplugin/extension/openflowplugin-extension-nicira/src/main/yang/openflowplugin-extension-nicira-action.yang:429:                default 0xfff8; // OFPP_INPORT
./openflowplugin/extension/openflowplugin-extension-nicira/src/main/yang/openflowplugin-extension-nicira-action.yang-430-            }

This is a YANG violation. YANGTOOLS-551 tracks the ability to detect these during parse, but this is an OFP problem.

 

Comment by Robert Varga [ 23/Jun/20 ]

I stand corrected, this is valid according to https://tools.ietf.org/html/rfc7950#section-9.2.1

Comment by Robert Varga [ 23/Jun/20 ]

The code in DefinitionGenerator needs to be smarter about detecting octal/hex values as per the spec.

Comment by Luis Gomez [ 25/Jun/20 ]

Issue seems to be fixed but the test reports a timeout (after 30 secs) reading from the api explorer URL
I will check if we need to increase this timeout or there is another issue.

Comment by Jamo Luhrsen [ 25/Jun/20 ]

yep. log here

30s is a long time though.

I see no log messages during the window of the apidocs call. karaf.log

ecelgp if you have bandwidth, maybe just pull the distro local and hit that URI to see.

Comment by Luis Gomez [ 26/Jun/20 ]

It is just a matter of time: https://git.opendaylight.org/gerrit/c/integration/test/+/90717

Comment by Jamo Luhrsen [ 26/Jun/20 ]

yes, I see. must be a TON of output coming back. I tried to open the step in robot
that logs the response.text and it crashed my browser. Thanks for fixing the apidocs
bug and the test code guys.

Generated at Wed Feb 07 20:15:41 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.