Hi Ajay, Sorry, I can’t really describe the signaling sequence more than that. I have basically no knowledge about the code, I have only tested ODL a bit, and observed the behavior I described below. I don’t actually know for a fact how ODL reads up the models from the node after the Hello message exchange, it’s just an assumption that a <get> on RFC 7895 /modules-state is done, and then uploads each of those models. Hopefully others who knows the code much better can answer detailed questions.
If you turn on detailed tracing, you can maybe see the exact signaling sequence. Since the trace is only a WARNing, I guess it shouldn’t be treated as something that is breaking anything, but I agree it could maybe have sufficed as a INFO trace. I think our reason to only advertise the basic capabilities in the Hello message is to be able to protect access to more sensitive application-specific models via <get> on /modules-state by applying access control mechanisms on that part of the model. //Martin From: Ajay Deep Singh Sent: den 9 maj 2019 11:33 To: Martin Sandberg <martin.sandb...@ericsson.com>; Emmett Cox <emmett....@est.tech>; Robert Varga <n...@hq.sk>; netconf-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Cc: Mariusz Sobucki <mariusz.sobu...@est.tech>; Paul Dennehy <paul.denn...@est.tech>; mdsal-...@lists.opendaylight.org Subject: RE: [netconf-dev] Help regarding Yang 1.1 actions Hi Martin, Thanks for your inputs. * Please can you help me understand how this “signaling sequence” work in ODl & how its initiated.? Also any light if you can throw on course of base action that are triggered from Odl to make sure Node capabilities are completely understood..? * “The application-specific Yang 1.1 models are not advertised in the Hello message”, In this context on adding any new Node (Yang Model) we should be encountering same waring message every time which gives false message in logs as it doesn’t Stop Odl to perform any operation on Node, guess this message should be updated..? I am fine with not finding specific capabilities in Hello message which I was expected to be present in it, as the Node is properly mounted in Odl I don’t suspect any problem there. Also will request other members In dev list to please comment on queries posted in below mail chain. Regards, Ajay From: Martin Sandberg Sent: Wednesday, May 8, 2019 12:32 PM To: Emmett Cox <emmett....@est.tech<mailto:emmett....@est.tech>>; Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>; netconf-...@lists.opendaylight.org<mailto:netconf-...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> Cc: Ajay Deep Singh <ajay.deep.si...@ericsson.com<mailto:ajay.deep.si...@ericsson.com>>; Mariusz Sobucki <mariusz.sobu...@est.tech<mailto:mariusz.sobu...@est.tech>>; Paul Dennehy <paul.denn...@est.tech<mailto:paul.denn...@est.tech>>; mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org> Subject: RE: [netconf-dev] Help regarding Yang 1.1 actions Hi Emmet, Regarding ” 2019-05-07T16:22:13,468 | WARN | remote-connector-processing-executor-12 | NetconfDevice | 347 - org.opendaylight.net conf.sal-netconf-connector - 1.9.0 | RemoteDevice{pnf-simulator}: Netconf device provides additional yang models not reported in hello message capabilities:” The warning message you see appears when the netconf device only advertises a subset of its capabilities in its Hello message, and ODL later in the signaling sequence receives more Yang 1.1 models when it performs an RCF 6022 get-schema or <get> on RFC 7895 /modules-state (which lists both 1.0 and 1.1 models). I got the same message when testing ODL with our nodes, which apparently only advertise NETCONF (base + any capabilities), YANG 1.0 models, and the YANG 1.1 RFC 7895 model. The application-specific Yang 1.1 models are not advertised in the Hello message, and are discovered by ODL later as described above. It didn’t cause any problem for me though, I could still perform configuration operations on the application-specific models. You can probably configure on your device which capabilities that shall be included in the Hello message, but you probably don’t need do it, is my guess. Or do you suspect you have problem with not getting all capabilities in the Hello message? Regards, Martin From: Emmett Cox <emmett....@est.tech<mailto:emmett....@est.tech>> Sent: den 8 maj 2019 12:13 To: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>; netconf-...@lists.opendaylight.org<mailto:netconf-...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> Cc: Ajay Deep Singh <ajay.deep.si...@ericsson.com<mailto:ajay.deep.si...@ericsson.com>>; Mariusz Sobucki <mariusz.sobu...@est.tech<mailto:mariusz.sobu...@est.tech>>; Martin Sandberg <martin.sandb...@ericsson.com<mailto:martin.sandb...@ericsson.com>>; Paul Dennehy <paul.denn...@est.tech<mailto:paul.denn...@est.tech>>; mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org> Subject: Re: [netconf-dev] Help regarding Yang 1.1 actions Hi Everyone, I emailed a while ago regarding the issues listed below( thanks for the response Robert, it was a great help). Since then myself and my team have investigated further into netconf, restconf and mdsal, and were hoping to get some clarification regarding a few questions. Firstly, we're wondering how exactly the wiring is done between restconf and mdsal - * based upon previous response our understanding is that the restconf-nb-rfc8040 module is used for handling restconf requirements etc. relating to that rfc, or beyond that rfc, and that we will have to add DOMActionService support to that module through the Rfc8040RestConfWiring class and several other classes in that module. Is our understanding correct here? * We are not sure whether this module will also generate the rest api's as part of the webpage, and what changes we would need to make to get this to work - or if we would need to make any changes. what other modules would be used in restconf to generate the rest api's and display them as part of the apidocs? * Our current understanding of how the objects are instantiated in restconf-nb-rfc8040 is through the @inject annotation , which passes through the various objects needed eg. schemaHandler, domDataBroker etc. We think that these object are already instantiated in mdsal etc, and that the restconf module will request this information and generate the rest api's etc. based upon this information. is this understanding correct? and if so, what modules, classes etc. are used in restconf to facilitate this. * We added a yang model to a simulated node and mounted it in odl - the yang model seems to come up in the apidocs, but we've been seeing this warning when we mount it: * 2019-05-07T16:22:13,468 | WARN | remote-connector-processing-executor-12 | NetconfDevice | 347 - org.opendaylight.net conf.sal-netconf-connector - 1.9.0 | RemoteDevice{pnf-simulator}: Netconf device provides additional yang models not reported in hello message capabilities: * Would you know what this message is referring to? I cannot see the added Yang model in hello capabilities listed by node in below snippet, i presume some more configuration needs to be added on simulator side can someone correct me if am wrong here. ? is that we need to add same model some where in MD-Sal or yangtool repo so that handshake between Odl and Node happens correctly.? * 2019-05-07T16:22:13,357 | DEBUG | nioEventLoopGroupCloseable-3-3 | NetconfXMLToHelloMessageDecoder | 345 - org.opendaylight.netconf.netty-util - 1.6.0 | Parsing message <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability * Finally, we (tried) mentioning during the kernel meeting yesterday that we would like to try arrange a meeting with anyone in the netconf, mdsal or controller projects to help build our understanding of how everything works - if anyone has any free time to help, or if there are any meeting calls where we could ask a few questions, please let us know. Regards, Emmett On 25/04/2019 16:48, Robert Varga wrote: On 25/04/2019 12:11, Emmett Cox wrote: Hi everyone, Hello, Myself and several members of my team are investigating what changes we would need to implement to allow restconf, mdsal and netconf to support Yang 1.1 actions, both in a clustered and non-clustered way. YANG Tools and MD-SAL support is there, on both DOM and Binding layers, supported by org.opendaylight.mdsal.dom.api.DOMActionService org.opendaylight.mdsal.dom.api.DOMActionProviderService org.opendaylight.mdsal.binding.api.ActionService org.opendaylight.mdsal.binding.api.ActionProviderService and their respective JVM-local implementations. To that end we've been trying to find documentation or guides regarding the various ODL modules relating to restconf, mdsal and netconf and determine which modules we need to change to get our use case working. Would any of you be able to point us in the direction of anything we could use to understand the modules, and where we could make a start regarding the changes we'll need to make? I am not sure about clustering support, that would be part of controller's sal-remoterpc-connector -- which needs to hook onto the DOMActionService/DOMActionProviderService instances available in Service Registry. I think the gossiping protocol should support advertizing actions without a change, but that needs to be checked out. For NETCONF, I think the only piece missing is the translator in ... sal-netconf-connector (and probably mdsal-netconf-connector, I always confuse the two). For RESTCONF, the old spec does not support actions, so there's nothing to be done for that. For the RFC8040 implementation, I think the wiring from HTTP to DOMActionService is missing (that would sit in restconf-nb-rfc8040). Regards, Robert
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
