On 25/02/2016 11:16, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
Hi Martin,
On 25/02/2016 09:31, Martin Bjorklund wrote:
Juergen Schoenwaelder <[email protected]> wrote:
On Thu, Feb 25, 2016 at 10:14:05AM +0100, Martin Bjorklund wrote:
Juergen Schoenwaelder <[email protected]> wrote:
On Thu, Feb 25, 2016 at 09:43:34AM +0100, Martin Bjorklund wrote:
Juergen Schoenwaelder <[email protected]> wrote:
On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote:
I think the use cases are rather obvious. I build a device and I like
to rearrange existing models into a beautiful hierarchy (for some
definition of beauty).
This would be pretty complicated. Suppose I define my own beautiful
structure like this:
container my-interfaces {
x:mount-point "if" {
x:mount-module "ietf-interfaces";
}
}
container my-routing {
x:mount-point "rtr" {
x:mount-module "ietf-routing";
}
}
Note that with the mount-point defined in my draft, each mount-point
becomes itw own "jailed" or "chrooted" tree. So references cannot
cross mount points.
Could be the same here.
In this case, we have references between ietf-routing and
ietf-interfaces. How would they work?
How do they work in your solution? If interfaces is jailed and routing
is jailed, how does routing refer to the interfaces?
My solution does not support "name module mount". It only supports
mouting of a "complete" set of modules (that are chrooted) - simply
because this is what we understand, have implemented, and have been
running for the last ~5 years. (The same goes for ODL, I believe).
OK. I understand now that the whole set of modules on a mount point
form one chroot environment. This was not clear to me yet but of
course makes a lot of sense. So a static schema mount would have to
define a set of modules and not just a single module to lead to the
same chrooted behavior.
Yes, but then you can't use it to define your own beautiful
structure.
I am not sure yet why this is the case.
Each such mount point is chrooted. This implies that if you want to
put module A in some place, and B has a reference to A, A and B must
be mounted together. Thus I cannot put them anywhere to form a
beautiful hierarchy.
As long as B is mounted in the same datastore as A then is it possible
that B could moved to be mounted on some other path?
Yes, but then you'd need some special syntax to say that they are
related.
Wouldn't any path references be sufficient to indicate whether the
modules are related?
References to/from B would need to be fixed up, or are you saying that
fixing the references is intractable?
I think it would be extremely complicated, both on the server and on
the client side.
This probably feels similar (but actually simpler) than mapping between
different sets of modules. E.g. mapping from OpenConfig modules to IETF
modules, or from OpenConfig/IETF modules to a native device schema.
I doubt whether this idea will be particularly well received, but:
Would it be possible to programmatically generate a new set of YANG
module definitions from the originals with updated paths/references.
I.e. both sets of module definitions model exactly the same data, just
the location of that data is in different places. A client could then
solely interact with the new set of YANG modules if they wished. A
function can be programmatically generated and used to map between the
two equivalent models with different node paths. I would imagine that
this mapping could be done either on the client side or server side.
Even if this approach is valid, it would appear to only really solve the
"can't use it to define your own beautiful structure.", and I'm not sure
whether that's an actual requirement here.
Rob
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
