Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

[Andy Bierman <[e-mail]>]

On Tue, Nov 14, 2017 at 1:22 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
> >    Whenever a client OSS implements some higher level logic for a network
> >    function, something that can not be implemented in a purely model
> driven
> >    way, it is always dependent on a specific version of the Yang Module
> >    (YAM). If the client finds that the module has been updated on the
> network
> >    node, it has to decide if it tries to handle it as it did the previous
> >    version of the model or if it just stops to avoid problems. To make
> this
> >    decision the client needs to know if the module was updated in a
> backward
> >    compatible way or not. This is not addressed with the current
> versioning.
>
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
>

There are lots of independent variables here.
The use of augment vs. new-module-version has a big impact on this problem.
But the IETF prefers to work on a module for several years, rather
than produce a base model that is extended by many other modules.
This approach has not produced a stable base of modules.
I think the idea is to worry less about stability and just iterate faster,
which might produce better results in the end.




>
> >    While having PYANG based checks for backward compatibility is a very
> good
> >    idea, a  comparison based check will never be a complete check. It is
> >    quite possible to change just the behavior of an rpc/action/etc.
> without
> >    changing the YANG definition.  This will only show up as a change of
> the
> >    description statement that can not be analyzed by PYANG.
>
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
>
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
>


In "real" code, we never remove or change an API. Never.
This is what Balazs is talking about.  You make new APIs,
perhaps using wrapper functions, but you do not break code
that depends on the existing APIs.

I would rather have code break immediately and very visibly,
rather than having it appear compatible but in fact changed
behavior silently breaks functionality.  These bugs are harder to find.

I guess if the compiler keep track of the major version for every import
somehow,
then it could issue a warning that "major version changed in import"
if a module diff is done.




>
> >    When upgrading a network node we might introduce non-backward
> compatible
> >    (NBC) changes. Today we need to introduce a new module for this. That
> >    means during the upgrade process the node must convert stored
> >    configuration instance data from ietf-routing to ietf-routing-2
> format.
> >    Instead of solving this data transformation/transfer problem just for
> a
> >    few NBC data nodes, we will have to do it for the full model. This is
> >    complicated. In many cases the transformation of a few NBC leafs can
> be
> >    handled by good defaults or with a small script. Transferring the full
> >    data set is more complicated. If we allow NBC updates in some cases
> this
> >    problem is avoided.
>
> In XML land, this is mostly a change of the namespace (not of the
> prefix) if one keeps the same structure, no? In JSON land, the change
> of the module name more directly becomes visible in instance data; but
> this is all encoding details.
>
> >    If we update the module from ietf-routing to ietf-routing-2 ? Do we
> keep
> >    the prefix?
>
> I guess you mean the namespace, not the prefix. You can use any prefix
> you like.
>
> >    In one sense it should be kept as it is the same module
> >    "logically"; we also might have stored data including the prefix
> >    (identityrefs, instance-identifiers). On the other hand having
> multiple
> >    modules with the same prefix is a problem. The only good solution is
> to
> >    allow incompatible updates in some cases.
>
> If we move towards allowing incompabile updates, then we need to have
> a mechanism to tell which versions of modules can work together and
> which combinations are affected by an incompatible update. We probably
> need to require strict import by revision or at least 'import by
> compatible revision' (whatever this means at the end).
>
> >    CH 1)
> >
> >    You write
> >    "The YANG data modeling language [RFC7950] specifies strict rules for
> >    updating..."
> >    and again
> >    "When the same YANG module name is kept, the new YANG module  revision
> >    must always be updated in a backward-compatible way."
> >
> >    I strongly disagree. While we have strict rules about even small
> >    modifications to existing schema, but you are allowed to
> >    deprecate/obsolete big parts of the model, thereby possibly deleting
> >    complete subtrees from the schema. That is anything but strict
> backward
> >    compatibility.
> >    I find this aspect of YANG inconsistent to the level that it would
> need an
> >    errata.
>
> Marking something deprecated / obsolete means you can not be sure this
> is implemented. But then, even definitions with status current may not
> be implemented (see deviations) or they may not be accessible to a
> client due to access control. However, if implemented and accessible,
> the guarantee today is that the semantics stay the same and don't
> change unexpectedly.
>
> >    So practically the current rules allow backward incompatible changes
> that
> >    can only be detected by a line by line comparison of the yang
> modules. In
> >    a system with semantic versioning, you could determine backward
> >    compatibility just by reading the version numbers.
>
> I do not see why you need a line by line comparison. With semantic
> versioning, you _hope_ the semantic version number is a good enough
> indicator. It might also be that your client is only using a subset
> that did not really change even though the semantic version number
> changed. Or the semantic version number indicates only minor changes
> that sill break your client.
>
> >    CH 2.3)
> >    As we need to create a new Yang Module (YAM) even for the smallest
> >    incompatible modification, this increases the number of modules.
>
> So it seems to boil down to the question whether foo and foo2 is
> significantly more expensive than foo { semver 1.x.y } and foo {
> semver 2.x.y }. The main argument seems to be that the later keeps
> references that involve module names or namespaces unchanged (but
> they may or may not mean different things).
>
> >    IMHO YANG package definition should be a separate issue, left out of
> this
> >    document. Andy has already provided some very good ideas about this
> topic.
>
> I think it is necessary to think about how the semantic version
> numbers are used. See my remark above about imports. If we allow
> incompatible changes, than this has side effects and I think we are
> not done by just adding a semantic version number without going
> working throught the implications.
>


I realized years ago that deprecated and obsolete definitions would create
the need for a compatible revision range (minver .. maxver) for every
import,
and the compatibility matrix would get increasing harder as the module
count grew

People called "package maintainers" do this work now in Linux-land.
The YANG Packages draft was an attempt to standardize a file format
that package maintainers would write and keep up-to-date.
Real testing and verification (with pyang and other tools) would be done
before a package can be released.  The common import mode would
be "greater-or-equal minver"  If a package maintainer decides the version
of "bar"
breaks module "foo", then an inclusive range is needed instead (minver ..
broken-1).

The current import-by-revision is too fragile and needs to be enhanced.



> /js
>
>
Andy



> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>