Modifying the model in the schema cache directory is a possible workaround for this.
This is a duplicate of 4577.
Ryan, I don't believe this bug is a duplicate of 4577.
Let say your netconf device runs ConfD, and its associated schema, foo.yang, import tailf-common.
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.
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.
The purpose of this bug is to have a way to mount schema containing import that are not supported/known by ODL.
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 https://tools.ietf.org/html/rfc6241#page-37 but this is not the one given when executing the edit-config.
I would like the netconf connector to be more lax when specified in the config.
Removing the mark as duplicate since I may not have adequately understood the problem; my apologies Alexis 
.
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...
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.
Is it fair to say this is more of an umbrella bug? I think the issues (1&2) described above may be in completely separate areas of the code.
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.
> 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...
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)
Here are some logs/warn when the netconf connector download/import schemas from the netconf device: https://gist.github.com/18a9d506f4aa638b7bc9
> 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.
Here are the logs/warn: https://gist.github.com/5c5558e29ffbc4b7a7fd 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.
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.
> Is it fair to say this is more of an umbrella bug? I think the issues (1&2) described above may be in completely separate areas of the code.
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.
(In reply to Alexis de Talhouët from comment #6)
> > 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...
>
> 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)
> Here are some logs/warn when the netconf connector download/import schemas
> from the netconf device: https://gist.github.com/18a9d506f4aa638b7bc9
>
> > 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.
>
> Here are the logs/warn: https://gist.github.com/5c5558e29ffbc4b7a7fd 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.
> 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.
>
> > Is it fair to say this is more of an umbrella bug? I think the issues (1&2) described above may be in completely separate areas of the code.
>
> 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.
Hi Alexis, does this bug has been solved in Boron?
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.
Also, bug-6251 is fixed, allowing to mount netconf devices having flawed models.
I'll have to look closer to see if that bug can be mark resolved.