Re: [netmod] submodules the hidden benefits

[Andy Bierman <[e-mail]>]

On Mon, Aug 10, 2020 at 1:56 PM Juergen Schoenwaelder <
[e-mail]> wrote:

> There are generic preprocessors such as good old cpp or m4 that can do
> wonderful things if there is a need to split large (YANG module) files
> into smaller pieces. The question here is what the added benefit is to
> build sub-modules into YANG itself. The argument I have heard is that
> this allows separate compilation of the sub-modules but even then I am
> not sure how well this works in practice and whether it is worth to
> save some CPU or IO time on developer machines. Perhaps someone can
> post concrete numbers that show the savings that can be obtained...
>
>
It is not possible in YANG 1.1 to compile a single submodule.
YANG allows the use of identifiers from other submodules without any
include-stmts.
It is not possible to compile (or read) a single submodule without the main
module and
all the correct revisions of the other submodules.

In this way submodules make readability much worse than imported modules.




> /js
>

Andy


>
> On Mon, Aug 10, 2020 at 08:08:02PM +0000, Sterne, Jason (Nokia -
> CA/Ottawa) wrote:
> > Thanks Tom.
> >
> > Versioning in current YANG specs and in the new versioning work has
> independent versioning available for modules and for sub-modules. The
> module version will always bump when something changes in a submodule, but
> each submodule has its own revision. So it can help consumers quickly see
> which parts of a large schema have and haven't changed.
> >
> > I agree that certain ways of dividing up modules, using groupings, etc
> can help or hinder readability. But I think that is orthogonal to
> submodules. YANG authors can make good or bad (*) readability decisions in
> a schema with submodules or a schema without submodules.  If a schema is
> divided up at the top level of a tree into submodules, then that is just as
> readable IMO as a large data model being divided up the same way into
> individual modules.  i.e. you can have your bgp module, your interfaces
> module, etc OR you can have your bgp submodule, your interfaces submodule,
> etc.
> >
> > (*) good vs bad is often pretty subjective and there are sometimes
> tradeoffs amongst readability, consistency, maintainability, etc. But again
> that is all orthogonal to submodules vs modules IMO.
> >
> > Rgds,
> > Jason
> >
> > > -----Original Message-----
> > > From: tom petch <[e-mail]>
> > > Sent: Monday, August 10, 2020 5:23 AM
> > > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>; Mahesh
> > > Jethanandani <[e-mail]>; [e-mail]
> > > Subject: Re: [netmod] submodules the hidden benefits
> > >
> > > From: netmod <[e-mail]> on behalf of Sterne, Jason
> (Nokia -
> > > CA/Ottawa) <[e-mail]>
> > > Sent: 07 August 2020 22:40
> > >
> > > I agree submodules can cause confusion, but I also agree with Mahesh
> that
> > > they can be useful to partition things for people using the modules.
> Especially
> > > for huge models (e.g. router vendor models). You can jump right to a
> > > subsection of the data (a bit like a document with chapters rather
> than one
> > > huge chapter).
> > >
> > > It can also be useful for consumers of the models for versioning (when
> you
> > > want to avoid multiple namespaces). If a model is made up of 30
> sub-modules,
> > > it might be useful to know that the "bgp" part changed while the other
> parts of
> > > the model didn't.
> > >
> > > <tp>
> > >
> > > Jason,
> > >
> > > Jan commented earlier that versioning happens at the module/namespace
> level
> > > in which case it would seem to me that all submodules will by
> definition have
> > > the same version so you cannot tell which submodules have changed,,
> > >
> > > I think too that there is a fallacy in the belief that dividing up
> something large
> > > makes it easier to use, understand etc.  Divide up code by procedure,
> > > subroutine etc and if you can provide a parameter or two input, and
> one or two
> > > results output, and all the complexity of data structures, validation,
> algorithms
> > > etc and hidden out of sight, then you have simplified.   But DDL is
> not like that.
> > > With a grouping or submodule, you need to know the internals, of what
> objects
> > > there are, how they are structured, what semantics they have, pretty
> much
> > > everything inside; it is just harder to find, to reference, to access
> because it has
> > > been wrapped up in something that gets in the way and tucked out of
> sight in
> > > some part of the I-D,
> > > Rather simplification comes from having the right structure in the
> model, which
> > > some WG are good at,
> > >
> > > Tom Petch
> > >
> > > Jason
> > >
> > > From: netmod <[e-mail]> On Behalf Of Mahesh
> Jethanandani
> > > Sent: Wednesday, August 5, 2020 6:43 PM
> > > To: [e-mail]
> > > Subject: Re: [netmod] submodules the hidden benefits
> > >
> > > A contrarian view:
> > >
> > > I find the use of sub-modules helpful when I want to use separate
> files to
> > > maintain part of the module that is logically separate, while
> > > maintaining/restricting the use of them to a single namespace.
> > > The fact that tools have a problem with trying to compile a sub-module
> can be
> > > addressed in the tools themselves.
> > >
> > >
> > > On Aug 5, 2020, at 2:44 PM, Reshad Rahman (rrahman)
> > > <rrahman=[e-mail]<mailto:rrahman=40cisco.com@dmarc.i
> > > etf.org>> wrote:
> > >
> > > Indeed
> > > https://github.com/netmod-wg/yang-next/issues/26
> > >
> > > On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev"
> <netmod-
> > > [e-mail] on behalf of vladimir@lightside-
> > > instruments.com<mailto:netmod-
> > > [e-mail]%20on%20behalf%20of%20vladimir@lightside-
> > > instruments.com>> wrote:
> > >
> > >    On 05/08/2020 18.48, Juergen Schoenwaelder wrote:
> > >
> > >
> > > I personally meanwhile believe that sub-modules add complexity with
> > > little extra value but this view surely is not shared by others.
> > >
> > >    +1. IMO removing sub-modules from YANG 2.0 should be on the list of
> > >    proposed changes.
> > >
> > >    /Vladimir
> > >
> > >    _______________________________________________
> > >    netmod mailing list
> > >    [e-mail]<mailto:[e-mail]>
> > >    https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>