Open Stack

On Jun 4, 2015 8:57 AM, "Monty Taylor" <mordred at inaugust.com> wrote:
>
> On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
> > On 06/04/2015 05:03 PM, Sean Dague wrote:
> >> On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
> >>> On 06/04/2015 04:40 PM, Ruby Loo wrote:
> >>>> Hi,
> >>>>
> >>>> In Kilo, we introduced microversions but it seems to be a
> >>>> work-in-progress. There is an effort now to add microversion into the
> >>>> API-WG's guidelines, to provide a consistent way of using
microversions
> >>>> across OpenStack projects [1]. Specifically, in the context of this
> >>>> email, there is a proposed guideline for when to bump the
microversion
> >>>> [2].
> >>>
> >>> As I understand this guideline tells to bump microversion on every
> >>> change which I strongly -1 as usual. Reason: it's bump for the sake of
> >>> bump, without any direct benefit for users (no, API discoverability is
> >>> not one, because microversion do not solve it).
> >>>
> >>> I'll post the same comment to the guideline.
> >>
> >> Backwards compatible API adds with no user signaling is a fallacy
> >> because it assumes the arrow of time flows only one way.
> >>
> >> If at version 1.5 you have a resource that is
> >>
> >> foo {
> >>    "bar": ...
> >> }
> >>
> >> And then you decide you want to add another attribute
> >>
> >> foo {
> >>    "bar": ...
> >>    "baz": ...
> >> }
> >>
> >> And you don't bump the version, you'll get a set of users that use a
> >> cloud with baz, and incorrectly assume that version 1.5 of the API
means
> >> that baz will always be there. Except, there are lots of clouds out
> >> there, including ones that might be at the code commit before it was
> >> added. Because there are lots of deploys in the world, your users can
> >> effectively go back in time.
> >>
> >> So now your API definition for version 1.5 is:
> >>
> >> "foo, may or may not contain baz, and there is no way of you knowing if
> >> it will until you try. good luck."
> >>
> >> Which is pretty aweful.
> >
> > Which is not very different from your definition. "Version 1.5 contains
> > feature xyz, unless it's disabled by the configuration or patched out
> > downstream. Well, 1.4 can also contain the feature, if downstream
> > backported it. So good luck again."
> >
> > If you allow to group features under one microversion, that becomes even
> > worse - you can have deployment that got microversion only partially.
> >
> > For example, that's what I would call API discoverability:
> >
> >  $ ironic has-capability foobar
> >  true
> >
> > and that's how it would play with versioning:
> >
> >  $ ironic --ironic-api-version 1.2 has-capability foobar
> >  false
> >  $ ironic --ironic-api-version 1.6 has-capability foobar
> >  true
> >
> > On the contrary, the only thing that microversion tells me is that the
> > server installation is based on a particular upstream commit.
> >
> > To me these are orthogonal problems, and I believe they should be solved
> > differently. Our disagreement is due to seeing them as one problem.
>
> We should stop doing this everywhere in OpenStack. It is the absolute
> worst experience ever.
>
> Stop allowing people to disable features with config. there is literally
> no user on the face of the planet for whom this is a positive thing.
>
> 1.5 should mean that your server has Set(A) of features. 1.6 should mean
> Set(A+B) - etc. There should be NO VARIATION and any variation on that
> should basically mean that the cloud in question is undeniably broken.
>
> I understand that vendors and operators keep wanting to wank around with
> their own narccisitic arrogance to "differentiate" from one another.
>
> STOP IT
>
> Seriously, it causes me GIANT amount of pain and quite honestly if I
> wasn't tied to using OpenStack because I work on it, I would have given
> up on it a long time ago because of evil stuff like this.
>
> So, seriously - let's grow up and start telling people that they do not
> get to pick and choose user-visible feature sets. If they have an unholy
> obsession with a particular backend technology that does not allow a
> public feature of the API to work, then they are deploying a broken
> cloud and they need to fix it.
>

So I just had dinner last night with a very large user of OpenStack (yes,
they exist)  whose single biggest request is that we stop "differentiating"
in the API. To them, any difference in the usability / behavior / API
between OpenStack deployment X and Y is a serious enough problem that it
will have two effects:
- vendor lock in
- they stop using OpenStack
And since avoiding single vendor lock in is important to them, well, really
it has only one result.

Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly
or non-discoverably between clouds. Or we simply won't have users.

> >>
> >> Looking at your comments in the WG repo you also seem to only be
> >> considering projects shipped at Major release versions (Kilo, Liberty).
> >> Which might be true of Red Hat's product policy, but it's not generally
> >> true that all clouds are at a release boundary. Continous Deployment of
> >> OpenStack has been a value from Day 1, and many public clouds are not
> >> using releases, but are using arbitrary points off of master.
> >
> > I don't know why you decided I don't know it, but you're wrong.
> >
> >> A
> >> microversion describes when a changes happens so that applications
> >> writers have a very firm contract about what they are talking to.
> >
> > No, they don't. Too many things can modify behavior - see above.
> >
> >>
> >>     -Sean
> >>
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/e3e2a1f8/attachment.html>