Hi Rob,
We've more privately discussed the bug-fix scenario and I'm sympathetic to it;
however, the requirement as written does not restrict itself to fixing module
definition bugs (e.g., a pattern or other value constraint) in some small but
incompatible way -- instead it's wide open and it will be [ab]used that way.
For example:
Here is what I am afraid the vendors want here: A developer on release train X
can easily change some data structure and then push the change into an
automated system which generates a new YANG module definition and revs a
version number -- all done! They don't have to deal with the inertia of making
this change in their release train Y or Z and they don't have to treat modules
as a stable API they are exporting, b/c they now have these new wonderful
versions from this work. Meanwhile we the users now have to deal with N forks
with all the various little incompatible changes random developers at the
company wanted to make without having to coordinate with their coworkers/other
internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't
be what we are optimizing for, let alone making a requirement.
Regarding enhancements, these are features, and are naturally augmentative. I
find it hard to believe we have a pressing need/requirement to support
non-backward compatible changes to existing modules in order to support
enhancements.
Thanks,
Chris.
Robert Wilton <rwil...@cisco.com> writes:
Hi Chris,
I think that there are two things driving this requirement:
What I regard as the key one, is that we want to be able to support the software
that we have shipped. In particular, we may need to fix bugs (perhaps at the
operators request) to a YANG model that has already been released. I.e. I think
that there are some scenarios, where forking a YANG module, although undesirable
is the right thing to do to include a fix. I don't believe that features or
deviations help solve this problem.
The two alternative solutions to being able to fix bugs, neither of which I
think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they ship in a
release.
(ii) If a bug is reported, operators are happy to wait until the bug has been
fixed in the current development release, and will migrate to that latest
release to pick up the fix.
The second thing driving this requirement is that vendors sometimes get asked
for enhancements to existing releases, perhaps because the latest development
release is too far out, or ask for an enhancement on the current train to be
back ported to an older release.
So, aiming to have stable YANG modules, trying a lot harder to avoid
non-backwards-compatible changes, and keeping new functionality to the head of
the development I completely agree with you on. But I still believe that there
are some valid scenarios, that should be limited as much as possible, where it
is necessary to make changes that sometimes break these rules, and having a
limited scheme that clearly indicates where such breakages have occurred is
probably better that the status quo of where the modules get changed, but the
operator doesn't get any useful indication of what type of changes are being
made.
Thanks,
Rob
On 25/10/2018 16:26, Christian Hopps wrote:
On Oct 20, 2018, at 1:55 PM, Joe Clarke <jcla...@cisco.com> wrote:
* New requirement 1.4 for supporting over-arching software releases
[ I read this as supporting various different module versions based on a
vendor's different software release trains. If this is wrong then the rest of
this doesn't apply and I would just ask for the text to be update to clarify
what it means. ]
How many operators/users have asked for this or indicated it's a requirement
for them?
What problem is intractable without this requirement being met, and what is the
cost of this requirement on the actual users?
I have pushed back multiple times on this b/c I believe this "requirement" is
really being pushed to make it easier for vendors (a small affected group) to develop
their software at the cost of their users (the much larger affected group) who would then
have to deal with multiple trains of the same module.
We already have features and deviations why are they not enough to deal with
functionality that is present or not in various software release/devices?
FWIW I'm not against making it easier to develop software, but we have to be
mindful if we are just pushing the cost (and magnifying it greatly) to other
people in the community.
Thanks,
Chris.
_______________________________________________
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
