Proposal: how to make incompatible changes

[Joseph Reynolds]

On 4/16/20 4:53 PM, Richard Hanley wrote:  -- also responding to Andrew 
Jeffery
> 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.

There is broad support to disable the phosphor REST APIs by default.  I 
understand we are waiting for a little more development work so this 
will go smoothly.  See comments in the review:
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344

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

I am trying hard to move the OpenBMC distro to be "secure by default".  
If we run into compatibility issues, I would try to put them in as 
DISTRO_FEATUREs, and then work to change the default to the secure setting.

An example for this is network IPMI.  I am (we are?) working toward 
allowing the BMC admin to disable the network IPMI service, but it would 
be enabled by default.  Then in future, we can change the default to 
disabled. ... (goes to look for old email)....

So I don't see a need for a second reference distro.

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

That sounds right to me.  I have less understanding of the BMC/host 
interface, so I'm ahpy ot let someone else lead there.

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

Agreed.

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