Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

Hello Andy, Martin's main problem was that we would need to update the original modules if the mount changes. I showed that design-time mount can be defined without modifying the original modules, if you specify the mount information in a separate file. So what specific problems are you concerned about? I do not want to make schema-mount a purely design-time solution. However I feel that the ability to define the mounts in design time is an important use-case that does not cause any problems. regards Balazs On 2016-08-26 19:53, Andy Bierman wrote: Hi, I agree with Martin about not specifying which YANG modules can be mounted under some mount point, in the YANG module. The mount point needs some basic properties (like "config root", "opstate root", whatever). Then data nodes are classified somehow (e.g. config=true/false) and that determines what content can be mounted under that mount-point. The combination of modules on the server needs to be a deployment decision to prevent issues like Martin describes below. Andy On Fri, Aug 26, 2016 at 5:38 AM, Martin Bjorklund <m...@tail-f.com> wrote: Ladislav Lhotka <lho...@nic.cz> wrote: > Martin Bjorklund <m...@tail-f.com> writes: > > > Hi, > > > > [replying to the first post in this (old) thread; the thread got a bit > > off-topic] > > > > Balazs Lengyel <balazs.leng...@ericsson.com> wrote: > >> Hello, > >> > >> As I understand it, Schema-mount today does not support an important > >> use-case which we definitely need, but others also indicated they > >> want. > >> > >> I want to specify off-line in design time which models will be mounted > >> where. Many of my nodes know in design-time what their model structure > >> will be, so I want a way to be able to document this in YANG. > > > > I'd like to understand this use case in more detail.  You say that > > that a "node knows in design-time" that YANG models it will use.  Thus > > it seems natural to be able to specify which other modules to mount in > > the YANG module itself. > > Did you have a chance to look into my slides from Berlin? I sketched some > solutions there. Well, that's a *solution*.  I'd like to understand the *problem* first ;) > > The problem I see with this is that it is very limited to the use case > > where each implementation defines its own YANG modules.  Suppose you > > have such a model, for example: > > > >    module A { > >      ... > >      mount ... { > >        mount-module B; > >        mount-module C; > >      } > >   } > > > > [pseudo-code for module A that specifies that it mounts B and C] > > > > Now, suppose you take this module A to another implementation, and it > > needs to augment something into module C; essentially this means that > > it would like to mount B, C and new module D.   This will not be > > possible unless it modifies module A. > > Not necessarily, D could contain an augment with a target specified by a > schema node identifier that uses nodes from both A and C. Not if B and D are defined as standalone modules, e.g. if B is ietf-interfaces and D is ietf-ip. > Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would > be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the > augment in ietf-ipv6-router-advertisements > >   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... } > > needn't be changed. This would be an entirely different kind of mount!  The current mount doesn't work like that; it doesn't give you visibility into the combined models - by design. > The major problem with this IMO is that it needs a new YANG statement. > > > > >> In > >> today's proposal the only way to find the Yang-Mounts is to read it > >> from the live node. > >> > >> * OAM integrators or operators want to be able to write CLI scripts > >>   and Netconf messages without accessing (expensive) real nodes. For > >>   this they need to know the mounts > >> * We want to generate some fancy documentation from YANG automatically > >>   in design-time. > > > > In a way this is no different from the situation today - in order to > > learn what YANG modules a device supports you need to connect and > > parse the <hello> message (or ietf-yang-library data in the near > > future).  This info could also be made available off-line in a file. > > Yup. So we just need some machine-readable description of the structure > of mounted schemas. > > > > > It should certainly be possible to define a file format that a device > > somehow could "publish" off-line that contained all the info that is > > available at run-time.  This file format could be exactly the same as > > you would get if you did a NETCONF <get/> operation with some filter > > to only retreive the ietf-yang-library data at the mount points. > > Well, if you have multiple levels of mounts, it will get messy: you > wouldn't know which yang-library data belongs to which mount point. Why not - imagine that you do a full <get/> on such a device, it will return the nested yang library data just fine. /martin > I believe some variation on YSDL could work, and as I wrote in another > thread, we could also incorporate datastores: after defining the > (multilevel) schemas, each datastore will get one assigned - and they > can also share them where needed. > > Lada > > > > > > > > > /martin > > > > > >> > >> * Many use cases need the possibility to mount schemas, but do not > >>   need the added complexity of schema changes in run-time. > >>   Notwithstanding the case of "YANG Features", for me the model schema > >>   is a mostly static description of a nodes capabilities. Most of the > >>   time I do not want to worry about the node changing its schema on > >>   the fly. > >> > >> > >> For this I propose 2 YANG extensions > >> > >> extension schema-mount { > >> description "Indicates that a YANG Module is to be mounted into > >> another module. > >> The argument specifies the name of the module to be mounted."; > >> argument mounted-module; > >> } > >> > >> extension schema-mount-target { > >> description "Specifies the target node under which a YANG module is to > >> be mounted. > >> The statement can only be used inside a schema-mount statement. > >> The argument follows the same rules as an augment statement's target. > >> argument target-node; > >> } > >> > >> The two extension statements can be placed in a separate module or the > >> mounted module. > >> > >> I don't insist on the solution, but I need the off-line/design-time > >> specification of yang-mount to be possible. IMHO the design-time mount > >> use-case is more important than the dynamic-mount. > >> > >> regards Balazs > >> -- > >> Balazs Lengyel                       Ericsson Hungary Ltd. > >> Senior Specialist > >> Mobile: +36-70-330-7909              email: balazs.leng...@ericsson.com > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod