Support multiple Yang model revisions for mounted nodes
Description
Activity
Added the binding spec dependency which should be enough
(In reply to Tomas Cere from comment #16)
> (In reply to Wojciech Dec from comment #15)
> > I don't see where I said that, but anyway...
>
> Well cleaning up the cache(== delete) after disconnect defeats the entire
> purpose(which is to avoid redownloading of schemas already present in the
> system) of the cache doesn't it?
A cache is by definition time-bound. Otherwise it becomes a rubbish dump. Anyway, the problem I opened is different...
>
> You don't want to use as you put it "nerd-knobs", that's fine, but this
> issue is not something we can fix on netconf level as this has to do with
> binding generation. The fix by Ryan can be of use to some people that
> encounter similar issues, or are willing to workaround the issue and should
> be mentioned here.
Sure, Ryan's fix can be useful to whoever has the problem, but mentioning it in the context of "it fixes" the issue raised by this bug is simply not true. If the component is wrong, let's change that.
(In reply to Wojciech Dec from comment #15)
> I don't see where I said that, but anyway...
Well cleaning up the cache(== delete) after disconnect defeats the entire purpose(which is to avoid redownloading of schemas already present in the system) of the cache doesn't it?
You don't want to use as you put it "nerd-knobs", that's fine, but this issue is not something we can fix on netconf level as this has to do with binding generation. The fix by Ryan can be of use to some people that encounter similar issues, or are willing to workaround the issue and should be mentioned here.
(In reply to Tomas Cere from comment #14)
> (In reply to Wojciech Dec from comment #13)
> > We may be talking about overlapping things.
> >
> > Adding a cache store directory that's a parameter in a mount point isn't
> > cool. Who on earth will ever know about that parameter, remember to use it,
> > when to change it, etc, when to clean the cache, besides perhaps the people
> > here?
>
> That's why there's documentation for this feature on the wiki, right?
"we have a wiki" is fine for non essential nerd-knobs.
Nerd-knobs, even if documented ones, for what is essential system behavior are not a good idea & never have been - the system should behave like that by default.
>
> That's why there's documentation for it on the wiki, right?
> (In reply to Wojciech Dec from comment #10)
>
> > So, what I'm arguing for here is that a cleaner solution be devised.
> > If we need to store each device's models in a separate cache dir, then at
> > least let's hide it from the user and clean it up on disconnect, etc. That's
> > just an idea.
>
> Seems like you don't really want to cache the models.
I don't see where I said that, but anyway...
>
> As for the BA app problem when it can't be used for multiple revisions of
> the same model the v2 binding spec should fix that but that's still some
> time away.
To summarize:
The issue raised by this bug, support BA app + devices with multiple model versions is fundamental system behavior.
The issue raised by this bug has not been fixed. Any fix for it must IMO not involve special "nerd knobs", i.e. it should be default.
The fix that has been attributed to this bug is for some other problem (revised models without version changes). IMO this other problem does not appear to be as fundamental, and a nerd-knob may be adequate.
(In reply to Wojciech Dec from comment #13)
> We may be talking about overlapping things.
>
> Adding a cache store directory that's a parameter in a mount point isn't
> cool. Who on earth will ever know about that parameter, remember to use it,
> when to change it, etc, when to clean the cache, besides perhaps the people
> here?
That's why there's documentation for this feature on the wiki, right?
That's why there's documentation for it on the wiki, right?
(In reply to Wojciech Dec from comment #10)
> So, what I'm arguing for here is that a cleaner solution be devised.
> If we need to store each device's models in a separate cache dir, then at
> least let's hide it from the user and clean it up on disconnect, etc. That's
> just an idea.
Seems like you don't really want to cache the models.
As for the BA app problem when it can't be used for multiple revisions of the same model the v2 binding spec should fix that but that's still some time away.
Current code supports only one version of a given Yang model mounted from remote devices. The presence of another same model revision breaks things.
Discussed at 2015 July ODL Summit...