Hi Chris,
On 25/10/2018 18:42, Christian Hopps wrote:
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.
I think that everyone on design team agrees that
non-backwards-compatible changes should be minimized and should really
only to used for bug fixes where it is anticipated that clients should
not be affected.
We want to allow non-backwards-compatible changes at the head of the
development tree, but again, I think that everyone agrees that keeping
it backwards compatible where possible is a good goal.
However, I think that there will be cases where a vendor decides that it
is right for an enhancement or non backwards compatible change to be
made to an already released module. I agree that this is highly
undesirable and an abuse of the rules, but I don't believe that whatever
versioning scheme we come up with will prevent vendors from doing this.
So then the question becomes: Is it better to pretend that this scenario
will never happen, design the versioning scheme so that it cannot be
expressed, which probably just means that clients will not be able to
detect when vendors do this by cheating the rules! Or is it better to
accept that this will sometimes occur, provide strong guidance as to why
this is bad practice and should be avoided, but have a versioning scheme
that still allows this to be expressed (in a bounded way)? I.e. even if
the vendors are doing something that is less than ideal, at least the
clients can spot where they have done this.
---
A separate concern that we had about ties this strictly to bug fixes is
that some one will ask for a definition of a bug fix. The design team
tried this but we couldn't even agree what a bug fix is, let alone agree
with a single definition of a bug fix as it related to a YANG module.
So our conclusion was that perhaps it is better not to tie the
requirements themselves to bug fix vs enhancement, because the boundary
between the two is too vague, and module writers will bend the rules.
So I see that the rules should be:
- backwards compatible bug fix - this is fine.
- non backwards compatible bug fix - this is fine if it is
pragmatically expected to not impact any clients, but careful
consideration is required if it might break clients.
- backwards compatible enhancement - not ideal, but pragmatically OK.
- non backwards compatible enhancement - this is bad and should be
avoided.
But if we don't want to define the difference between a bug fix vs
enhancement then I think that you end up with the most general
requirement being that we do want to allow for non-backwards-compatible
changes in released modules to accommodate the bug fix scenario, but the
expectation (and guidance) will be that they should only be used for bug
fixes.
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.
I agree. It was a backwards compatible enhancement that I was considering.
Thanks,
Rob
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
