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

[Robert Wilton <[e-mail]>]

On 25/07/2018 12:03, Juergen Schoenwaelder wrote:
> On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote:
>> But if fixing a definition requires a whole new module name then I think
>> that causes lots of problems (e.g. consider needing to change ief-interfaces
>> to ietf-interfaces-v2 because of changing one random leaf).
> I assume this depends a lot on how clients are written but chances are
> that a significant portion of clients are written such in such a way
> that dealing with multiple namespaces is difficult. (But yeah, dealing
> with multiple versions in the same namespace likely is also difficult
> for them.)
Yes, I think that this comes down to client implementation.

If clients are looking for a universally unique identifier for a given 
datanode then I think that they already have to consider the triple 
(module, path, X), where X potentially covers:
(i) per device/vendor/release deviations,
(ii) possibly which revision a data node was first introduced in, or 
obsoleted in,
(iii) different YANG features enabled on different devices,
(iv) semantic versioning - at least in the case of the OpenConfig YANG 
modules,
(v) non backwards compatible changes (both bug fixes, and more 
significant refactoring).

Hence, I'm still not really convinced that adding a semantic version 
number is introducing something that robust clients don't have to 
already have handle today (even if they didn't have to cope with (iv) or 
(v), they still may have to cope with (i) and (ii) and (iii) regardless.

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.

It is also worth pointing out that the version selection scheme that I 
described is really just a way to potentially move the mapping layer 
from the client code to the server.  Fundamentally it is doing the same 
job and serving the same purpose.


>
> 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.

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 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.

>
> At the end, code that needs to support multiple versions is always
> going to be to some extend ugly. Whether the uglyness is in namespace
> bindings or version checks is likely more a question of taste. I
> believe code uglyness is not really driving this but the desire to be
> more agile and "lets release and then fix clients when they break" may
> be more dynamic than "lets release and then wait for clients to get
> updated".
With version selection, servers would still have the opportunity of not 
breaking clients, although it doesn't seem that likely to me that 
vendors will spend the effort to implement this.  But I still see that 
allowing the option to do this is a good idea (perhaps as a separate 
experimental draft).

>
>> 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.

>
> 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.

Thanks,
Rob


>
> /js
>