https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-90 netconf <p>Be able to make the netconf connector configurable (whether the connector should use device models for netconf base operations or a standard one).</p> <p>Add the functionality for the netconf connector to ignore any schemas touching base netconf operations and use pre-loaded models that are already in ODL.</p> <p>The purpose is to have an even more open netconf connector, so it can be compatible with any netconf server, for instance ConfD with all its tail-f extensions.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-90

Be able to configure whether the connector uses device models or standards one for netconf base operations

Improvement Confirmed Unresolved Unassigned Alexis de Talhouët Mon, 26 Oct 2015 13:58:39 +0000 Tue, 13 Aug 2019 07:38:40 +0000 netconf 0 4 <p>Modifying the model in the schema cache directory is a possible workaround for this.</p> <p>This is a duplicate of 4577.</p> <p>Ryan, I don't believe this bug is a duplicate of 4577.</p> <p>Let say your netconf device runs ConfD, and its associated schema, foo.yang, import tailf-common.</p> <p>When you connect this device to ODL using the current netconf connector, the schema will be loaded in the cache/schema folder. That's fine, and the path for the folder where to save the schema can now be configure thanks to 4577.</p> <p>Although, when you try to mount this device, it will fail to mount the associated schema, foo.yang, because of the tailf-common stuff that are in it. </p> <p>The purpose of this bug is to have a way to mount schema containing import that are not supported/known by ODL.</p> <p>Another use case for this bug: again, let say we use a netconf device running ConfD. Some tailf models does change the output of the edit-config RPC, thus the returned "OK" isn't recognized by ODL. ODL is confused because it's expecting a specific encapsulation for the "OK" based on the RFC 6241 <a href="https://tools.ietf.org/html/rfc6241#page-37" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#page-37</a> but this is not the one given when executing the edit-config.</p> <p>I would like the netconf connector to be more lax when specified in the config.</p> <p>Removing the mark as duplicate since I may not have adequately understood the problem; my apologies Alexis <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/>.</p> <p>1) Okay so your issue is that there are some Yang parser errors/exceptions for the models you are trying to import... can you add those exception stack traces to this bug? We have had issues mounting tail-f as well...</p> <p>2) Regarding the "OK" message, do you have a trace or something of this? I am just asking since we have also pushed for some leniency in the interpretation of standards; usually we have been told that we should be standards compliant by default, and have some sort of option to turn on leniency. Is the frame that tail-f returns standards compliant? I am not an expert on this RFC by any means, so any information you provide is helpful.</p> <p>Is it fair to say this is more of an umbrella bug? I think the issues (1&amp;2) described above may be in completely separate areas of the code.</p> <p>I understand the frustration with trying to get things to mount in ODL; there seem to be a lot of cases in which things simply won't work because different people interpreted the spec differently.</p> <p>&gt; 1) Okay so your issue is that there are some Yang parser errors/exceptions for the models you are trying to import... can you add those exception stack traces to this bug? We have had issues mounting tail-f as well...</p> <p>It's not for the models I'm tying to import, it is more regarding the model I'm trying to mount. I don't anymore have the stack traces for that because I changed the model of the netconf device so it can mount properly. That being said, I shall change it again just to provide the stack trace. (although can't do it right now, maybe in a couple of weeks)<br/> Here are some logs/warn when the netconf connector download/import schemas from the netconf device: <a href="https://gist.github.com/18a9d506f4aa638b7bc9" class="external-link" target="_blank" rel="nofollow noopener">https://gist.github.com/18a9d506f4aa638b7bc9</a></p> <p>&gt; 2) Regarding the "OK" message, do you have a trace or something of this? I am just asking since we have also pushed for some leniency in the interpretation of standards; usually we have been told that we should be standards compliant by default, and have some sort of option to turn on leniency. Is the frame that tail-f returns standards compliant? I am not an expert on this RFC by any means, so any information you provide is helpful.</p> <p>Here are the logs/warn: <a href="https://gist.github.com/5c5558e29ffbc4b7a7fd" class="external-link" target="_blank" rel="nofollow noopener">https://gist.github.com/5c5558e29ffbc4b7a7fd</a> The frame that tail-f return isn't compliant, and this is why ODL is confuse. This end up with ODL ending the netconf session and recreate it.<br/> I believe ODL's implementation of the RFC 6241 really respected it. I'm far from having a great knowledge of the RFC, but I know ODL is too strict and it would be nice to make it more lax though configuration.</p> <p>&gt; Is it fair to say this is more of an umbrella bug? I think the issues (1&amp;2) described above may be in completely separate areas of the code.</p> <p>I completely agree, I opened this bug as an enhancement for Boron after talking with Maros. It is an umbrella bug, and it needs to be correctly break done so underlying bugs can be scheduled in Boron. I believe this can be done during next ODL Dev forum (February I believe). I think the two issues you described are absolutely relevant to this bug.</p> <p>(In reply to Alexis de Talhouët from comment #6)<br/> &gt; &gt; 1) Okay so your issue is that there are some Yang parser errors/exceptions for the models you are trying to import... can you add those exception stack traces to this bug? We have had issues mounting tail-f as well...<br/> &gt; <br/> &gt; It's not for the models I'm tying to import, it is more regarding the model<br/> &gt; I'm trying to mount. I don't anymore have the stack traces for that because<br/> &gt; I changed the model of the netconf device so it can mount properly. That<br/> &gt; being said, I shall change it again just to provide the stack trace.<br/> &gt; (although can't do it right now, maybe in a couple of weeks)<br/> &gt; Here are some logs/warn when the netconf connector download/import schemas<br/> &gt; from the netconf device: <a href="https://gist.github.com/18a9d506f4aa638b7bc9" class="external-link" target="_blank" rel="nofollow noopener">https://gist.github.com/18a9d506f4aa638b7bc9</a><br/> &gt; <br/> &gt; &gt; 2) Regarding the "OK" message, do you have a trace or something of this? I am just asking since we have also pushed for some leniency in the interpretation of standards; usually we have been told that we should be standards compliant by default, and have some sort of option to turn on leniency. Is the frame that tail-f returns standards compliant? I am not an expert on this RFC by any means, so any information you provide is helpful.<br/> &gt; <br/> &gt; Here are the logs/warn: <a href="https://gist.github.com/5c5558e29ffbc4b7a7fd" class="external-link" target="_blank" rel="nofollow noopener">https://gist.github.com/5c5558e29ffbc4b7a7fd</a> The<br/> &gt; frame that tail-f return isn't compliant, and this is why ODL is confuse.<br/> &gt; This end up with ODL ending the netconf session and recreate it.<br/> &gt; I believe ODL's implementation of the RFC 6241 really respected it. I'm far<br/> &gt; from having a great knowledge of the RFC, but I know ODL is too strict and<br/> &gt; it would be nice to make it more lax though configuration.<br/> &gt; <br/> &gt; &gt; Is it fair to say this is more of an umbrella bug? I think the issues (1&amp;2) described above may be in completely separate areas of the code.<br/> &gt; <br/> &gt; I completely agree, I opened this bug as an enhancement for Boron after<br/> &gt; talking with Maros. It is an umbrella bug, and it needs to be correctly<br/> &gt; break done so underlying bugs can be scheduled in Boron. I believe this can<br/> &gt; be done during next ODL Dev forum (February I believe). I think the two<br/> &gt; issues you described are absolutely relevant to this bug.</p> <p>Hi Alexis, does this bug has been solved in Boron?</p> <p>Wang, sorry I missed the comment. I think this is getting partially address with bug-6346, at least for the part that allows to over-ride non-module capabilities and use them.</p> <p>Also, bug-6251 is fixed, allowing to mount netconf devices having flawed models.</p> <p>I'll have to look closer to see if that bug can be mark resolved.</p> Blocks NETCONF-101 Development External issue ID 4530 External issue URL ODL SR Target Milestone Rank 0|i01we7: