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>; Robert Varga <n...@hq.sk>;
netconf-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Cc: Ajay Deep Singh <ajay.deep.si...@ericsson.com>; 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 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
