Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jul 25, 2018 at 05:25:32PM +0100, Robert Wilton wrote:
> 
> 
> One alternative way to build a robust client would be to have an internally
> defined schema by the client (perhaps based on open models, or perhaps a
> particular version of vendor models, possibly with some deviations, or their
> own model) which they can then map onto one or more per device schema.  So
> within a particular schema (internal or device specific) then (module name,
> path) uniquely resolves to a data node with particular properties; but
> between different schema (e.g. for each different device) then the same
> (module name, path) pair is allowed to resolve to a different uniquely
> defined property.
> 
> A layer of mapping is performed between the internal schema and the device
> schema for whichever devices/sw-versions it needs to interoperate with.  The
> more closely the two schema align, the easier the mapping is to achieve. 
> This is also why, ultimately, that determining whether changes are backwards
> compatible or not needs to be done at the schema level (which takes into
> account deviations and features), and also the per data node level.
>

This is what NMSes used to do and well still nasty work. But I assume
people think about much simpler clients, the scripts that often clue
the things together.

> > What really chances here is the adaptation process: Today, a client
> > will not bother to use a new namespace (a new version) unless it was
> > programmed to do so (opt-in). The proposed new versioning scheme
> > effectively means that client will automatically use new versions
> > until the client got told to be careful where necessary (and I assume
> > that in most cases this means until the client failed and then got
> > fixed, an opt-out process).
> My main concern with using module name for major version changes is that it
> forces a name change for each data node in that module, regardless of
> whether that node has actually changed.  This inherently feels like the
> wrong this to do.  If a data node hasn't changed then ideally you want it to
> remain unchanged on the same path.  So the alternative way that RFC 7950
> supports today is to keep the module name the same but introduce new names
> for all identifiers that have been changed in a non backwards compatible
> way, making use of status deprecated/obsolete.

Yes, you can decide between the two options today. If only leaf foo
needs an non-backwards compatible update, you create a new leaf
bar. If the majority of leafs in a module need a non-backwards
compatible update, you create a new module.

> However, it isn't clear to me that handling the old and new values within
> the same schema is always a good thing to do.  I generally prefer the idea
> of doing version selection (if anyone chooses to support this) so that a
> given value is only reported once.

I wonder how this will ever work with vendor modules, ietf modules,
ieee modules, openconfig modules, etc. all overlapping, sometimes more
and sometimes less. You would have to create distinct views onto the
same instrumentation if you do not want to have overlapping values.

> > I can understand why some people believe a conservative opt-in
> > approach is desirable for them and I can understand why some other
> > people believe an optimistic approach opt-out approach is desirable
> > for them. There are likely good arguments for both and this makes it
> > difficult to pick one.
> My feeling (and I don't have hard evidence to back this up) is that clients
> are generally less impacted by keeping the name the same rather than
> changing the module name for every major version change.

Not sure I parse this correctly...

> > > The YANG 1.1 way is to define a new definition and then deprecate
> > > the broken one. But this has negative consequences as well,
> > > e.g. does writing to the old leaf automatically also write to the
> > > new leaf at the same time? Are both returned in a get request? What
> > > if a different client only writes to the new leaf?
> > Sure, duplicate or overlapping config objects is something we usually
> > try to avoid. In general, I assume a server would try to keep such
> > overlapping leafs in sync. But then, this is an issue that appears in
> > any scheme that allows access to multiple versions of a leaf (or
> > overlapping leafs in general, i.e. a standard object and a vendor
> > version of it).
> I still think that clients may struggle to process configuration in a get
> request that they had not configured, and hence were not expecting.

Maybe, maybe not. Perhaps things get simpler if the relationship of
foo replacing bar is machine readable.

> > The point I was trying to make was a different one, namely that today
> > we have a way to expose multiple versions of a leaf by using a new
> > (module, path) name while with a (module, path, version) naming
> > system, our protocols need extensions to expose multiple versions of a
> > leaf (or we declare that servers will never expose multiple versions
> > and that clients must always adapt to the version currently offered by
> > a server).
> So, I think that constraint should be that for a given schema (i.e. set of
> implemented modules) there can be only a single definition for a (module,
> path) pairing.  I see the version information, much like deviations, as just
> a mechanism to help clients (and readers) to spot where the definition may
> deviate from what they were previously anticipating.
> 
> In all cases, I think that minimizing backwards incompatible changes is the
> right thing to do, and I suspect that as YANG gains more traction, more of
> the latent bugs will get fixed, models will harden, and churn will
> decrease.  But I think that vendors will always want an easy way to fix
> bugs, and to change the model in the case that the implementation has
> radically changed, or when the schema is being cleaned up.

Well, part of the story line is that it is necessary to produce half
baked modules faster and then to fix them iteratively. And there is
likely some truth to it since implementation of models helps to
understand how to do them better. But once you are in production, you
hate moving APIs and stability is suddenly a big value.

Perhaps all we need is a marker that says "this module is still
experimental and hence it does not provide any backwards compatibility
promises". Clients using these modules then know that newer revisions
can break things.

 module ietf-foo {
    stability alpha;
 }

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>