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