[NETCONF-822] Discover RPC operation through RESTCONF is failing with response 500 Created: 29/Sep/21  Updated: 05/Oct/21  Resolved: 05/Oct/21

Status: Resolved
Project: netconf
Component/s: restconf-nb
Affects Version/s: 2.0.5
Fix Version/s: 2.0.6

Type: Bug Priority: Highest
Reporter: Peter Suna Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: pt, regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Capture.PNG     Text File karaf.txt    
Issue Links:
Relates
relates to YANGTOOLS-1337 Add EffectiveModuleContext.findModule... Resolved
relates to YANGTOOLS-1336 Improve SchemaInferenceStack diagnostics Resolved
relates to YANGTOOLS-1338 Generate ietf-restconf operations lea... Resolved

 Description   

Steps to reproduce:

  • Start Karaf
  • Install RESTCONF and topology features: "feature:install odl-restconf-all odl-netconf-topology"
  • Send get request to retrieve server RPC operations: "curl --request GET 'http://localhost:8181/rests/operations' "

 
The request will fail because in SchemaInferenceStack class is trying to find RPC with name "operations" instead of returning all found RPCs operations:

Caused by: java.lang.IllegalArgumentException: Data tree child (urn:ietf:params:xml:ns:yang:ietf-restconf)operations not present
	at org.opendaylight.yangtools.yang.model.util.SchemaInferenceStack.lambda$pushData$5(SchemaInferenceStack.java:799) ~[?:?]
	at java.util.Optional.orElseThrow(Optional.java:408) ~[?:?]
	at org.opendaylight.yangtools.yang.model.util.SchemaInferenceStack.pushData(SchemaInferenceStack.java:798) ~[?:?]
	at org.opendaylight.yangtools.yang.model.util.SchemaInferenceStack.pushFirstData(SchemaInferenceStack.java:807) ~[?:?]
	at org.opendaylight.yangtools.yang.model.util.SchemaInferenceStack.pushData(SchemaInferenceStack.java:787) ~[?:?]
	at org.opendaylight.yangtools.yang.model.util.SchemaInferenceStack.enterDataTree(SchemaInferenceStack.java:473) ~[?:?]
	at org.opendaylight.yangtools.yang.data.util.NormalizedNodeStreamWriterStack.enterDataTree(NormalizedNodeStreamWriterStack.java:187) ~[?:?]
	at org.opendaylight.yangtools.yang.data.util.NormalizedNodeStreamWriterStack.startContainerNode(NormalizedNodeStreamWriterStack.java:259) ~[?:?]
	at org.opendaylight.yangtools.yang.data.codec.gson.JSONNormalizedNodeStreamWriter.startContainerNode(JSONNormalizedNodeStreamWriter.java:305) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter.wasProcessedAsCompositeNode(ParameterAwareNormalizedNodeWriter.java:265) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter.write(ParameterAwareNormalizedNodeWriter.java:117) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter$OrderedParameterAwareNormalizedNodeWriter.write(ParameterAwareNormalizedNodeWriter.java:323) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.JsonNormalizedNodeBodyWriter.writeNormalizedNode(JsonNormalizedNodeBodyWriter.java:134) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.JsonNormalizedNodeBodyWriter.writeTo(JsonNormalizedNodeBodyWriter.java:72) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.JsonNormalizedNodeBodyWriter.writeTo(JsonNormalizedNodeBodyWriter.java:47) ~[?:?]

More in attached Karaf logs and debug capture.

 Comments   
Comment by Robert Varga [ 29/Sep/21 ]

So from cursory glance there seems to be a disconnect between OperationsContainerSchemaNode, which reports its SchemaPath as /operations and JsonNormalizedNodeBodyWriter, which uses that to guide the JSON codec, which in turn talks to SchemaInferenceStack. Previously we just passed the OperationsContainerSchemaNode down the codec pipeline, which did its magic and happened to not trip over things like leafrefs (because there none), it's just simple empty leaves.

This is rather unfortunate, as there is no straightforward way to fix this while retaining YANG-based codecs. Essentially ietf-restconf.yang forbids those leaves from existing as a baseline, simply because they do not exist in YANG model. The 'description' statement, no matter how long it is, simply is not something YANG parser can use to conjure up the corresponding 'leaf' statements into existence.

Comment by Robert Varga [ 29/Sep/21 ]

So there are essentially two things we could do:

  • ditch codecs for /operations and bypass the issue at least until the time someone else tries to decode things based on yang:data where this appears – essentially do not return NormalizedNodeContext from RestconfOperationsService.getOperations(UriInfo).
  • teach YANG parser about this particular wart, i.e. make it generate the missing leaf statements, so the generated NormalizedNode structure is valid. Since we already have a rfc8040-parser-support, its extension should be able to introduce these leaves as part of the reactor execution. Even if we do that, though, RESTCONF will need to be updated to not do the hack it is now doing and pass a proper EffectiveModelInference, not SchemaPath, down to codec. Everything needed for that should already be in place with YANGTOOLS-1297.

The second option does not work for bierman02, as it does not have a YANG extension and therefore YANG parser will not do anything for it.

So let us:

  • go with the first option for both bierman02 and rfc8040 first, which will resolve the immediate issue at hand
  • follow up with the rfc8040-parser-support improvement, which feels like something we should do since we explicitly know about the issue (by implementing the rc:yang-data extension)
  • switch rfc8040 back if we feel that is the best way we can do this

 

Comment by Robert Varga [ 29/Sep/21 ]

So this is a major regression and it warrants a standalone release and perhaps re-spinning the (now 2 weeks late) Phosphorus GA.

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