Proposal: how to make incompatible changes

[Richard Hanley]

Thank you for bringing this up.  I really think that some policy discussion
is useful here.  I also 100% agree that forward compatibility should be our
goal here.

When I think about incompatible changes I tend to group them into one of
two categories:
1) A design change goes in the opposite direction than what previous
versions offered, and the old feature needs to be shut off.
2) New features/designs are made, and supporting several different options
at the same time is difficult

Security changes are often in the former category. I remember a few months
back there was a thread about removing the DBus rest interface as a default
service for security reasons.  Brad's point at the time was (I may be
paraphrasing here) that we need to maintain support for any currently
supported use case or be able to support their migration.

Now another point in that thread was that some users are going to care more
about security than compatibility, and vice versa. One possible solution is
to create a second secure phosphor reference implementation.

Here is the thread I'm talking about:
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html

Having two reference implementations (profiles, tracks, or whatever we want
to call it) isn't without risk.  If things ever diverge too far, then the
overhead might be larger than supporting forward compatibility.  However, I
would like to get to a place where changes of that sort can be made
accessible to early adopters, combined with a clearly communicated
deprecation/migration plan.


On Wed, Apr 15, 2020 at 10:01 PM Andrew Jeffery <andrew at aj.id.au> wrote:

> > Applicability.
> >
> > These guidelines are for the BMC's "intended external user interfaces".
> > For example, its management interfaces including its web server and all
> > REST APIs.  I haven't given much thought to the BMC/host interfaces or
> > interfaces internal to the BMC.  IMHO, it is less important to maintain
> > compatibility in these areas.
>
> Lets split this. My feelings are
>
> 1. Inband (BMC/Host) interfaces are in the same class as "intended
> external user interfaces" and therefore should not have incompatible
> changes unless _absolutely_ necessary. What we implement here should
> have passed through a specification process under e.g. DMTF.
>
> 2. Interfaces between applications on the BMC (e.g. D-Bus interfaces)
> is the class where compatibility is less critical, on systems that do not
> expose the D-Bus interfaces via REST. However, while any system exists
> that exposes the D-Bus interfaces via REST we must constrain changes
> to these interfaces as well.
>
> > For example, if you need an incompatible
> > change in an internal interface, you have a smaller set of users who
> > ought to be active in the project, and can give you feedback and adapt
> > within a release cycle.
> >
>
> This is true for interfaces between BMC components, it's not true of the
> host firmware interfaces, hence my split above.
>
> When we remove the ability to directly access the D-Bus interfaces via
> REST we will gain a lot more freedom as the D-Bus interfaces then truly
> become internal.
>
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200416/5bc05e99/attachment-0001.htm>