Open Stack

On 01/23/2017 08:11 AM, Chris Dent wrote:
> On Wed, 18 Jan 2017, Chris Dent wrote:
> 
>> The review starts with the original text. The hope is that
>> commentary here in this thread and on the review will eventually
>> lead to the best document.
> 
>     https://review.openstack.org/#/c/421846
> 
> There's been a bit of commentary on the review which I'll try to
> summarize below. I hope people will join in. There have been plenty
> of people talking about this but unless you provide your input
> either here or on the review it will be lost.
> 
> Most of the people who have commented on the review are generally in
> favor of what's there with a few nits on details:
> 
> * Header changes should be noted as breaking compatibility/stability
> * Changing an error code should be signalled as a breaking change
> * The concept of extensions should be removed in favor of "version
>   boundaries"
> * The examples section needs to be modernized (notably getting rid
>   of XML)
> 
> There's some concern that "security fixes" (as a justification for a
> breaking change) is too broad and could be used too easily.
> 
> These all seem to be good practical comments that can be integrated
> into a future version but they are, as a whole, based upon a model
> of stability based around versioning and "signalling" largely in the
> form of microversions. This is not necessarily bad, but it doesn't
> address the need to come to mutual terms about what stability,
> compatibility and interoperability really mean for both users and
> developers. I hope we can figure that out.
> 
> If my read of what people have said in the past is correct at least
> one definition of HTTP API stability/compatibility is:
> 
>    Any extant client code that works should continue working.
> 
> If that's correct then a stability guideline needs to serve two
> purposes:
> 
> * Enumerate the rare circumstances in which that rule may be broken
>   (catastrophic security/data integrity problems?).
> * Describe how to manage inevitable change (e.g., microversion,
>   macroversions, versioned media types) and what "version
>   boundaries" are.
> 
> And if that's correct then what we are really talking about is
> reaching consensus on how (or if) to manage versions. And that's
> where the real contention lies. Do we want to commit to
> microversions across the board? If we assert that versioning is
> something we need across the board then certainly we don't want to
> be using different techniques from service to service do we?
> 
> If you don't think those things above are correct or miss some
> nuance, I hope you will speak up.
> 
> Here's some internally-conflicting, hippy-dippy, personal opinion
> from me, just for the sake of grist for the mill because nobody else
> is yet coughing up:
> 
> I'm not sure I fully accept the original assertion. If extant client
> code is poor, perhaps because it allows the client to make an
> unhealthy demand upon a service, maybe it shouldn't be allowed? If
> way A to do something existing, but way B comes along that is better
> are we doing a disservice to people's self-improvement by letting A
> continue? Breaking stuff can sometimes increase community
> engagement, whether that community is OpenStack at large or the
> community of users in any given deployment.

This counter assertion seems a lot like blaming the consumer for trying
to use the software, and getting something working. Then pulling that
working thing out from under them with no warning.

We all inherited a bunch of odd and poorly defined behaviors in the
system we're using. They were made because at the time they seemed like
reasonable tradeoffs, and a couple of years later we learned more, or
needed to address a different use case that people didn't consider before.

If you don't guaruntee that existing applications will work in the
future (for some reasonable window of time), it's a massive turn off to
anyone deciding to use this interface at all. You suppress your user base.

If, when operators upgrade their OpenStack environments, there consumers
start complaining to them about things breaking, operators are going to
be much more reticent on upgrading anything, ever.

If upgrades get made harder for any reason, then getting security fixes
or features out to operators/users is not possible. They stopped taking
them. And when they are far enough back from master, it's going to be
easier to move to something else entirely than both upgrading OpenStack,
which effectively will be something else entirely for their entire user
base.

This is the spiral we are trying to avoid. It's the spiral we were in.
The one where people would show up to design summit sessions for years
saying "for the love of god can you people stop breaking everything
every release". The one where the only effective way to talk to 2
"OpenStack Clouds" and get them to do the same thing for even medium
complexity applications what to write your own intermediary layer.

This is a real issue. A real issue raised by users and other project
teams. I do understand that in other contexts / projects that people
have been involved in, this may not have been considered an issue. But I
would assert it is one here.

So before reopening the exploration of approaches (or the need to do
anything at all), we should probably narrow the focus of whether
guaruntees to the user that their existing code will continue to work is
something that we need / want. I don't see any new data coming into our
community that this is less important than it was 4 years ago.

Because consumers of interfaces aren't usually doing the for
self-improvement reasons. They are doing that because there is work they
need to get done. And their schedule about when they can spend the time
to do it better may not align with when upstream can come up with a
better way, or when their cloud provider is rolling that out to them.

	-Sean

-- 
Sean Dague
http://dague.net