Open Stack

So we should have told the folks to so developing agent? (Not sure why you
all think I'm talking about us) Maybe.

But anyway anyone deliberately ignores my points, so I'm done with this
discussion.
04 июня 2015 г. 18:17 пользователь "Devananda van der Veen" <
devananda.vdv at gmail.com> написал:

>
> 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
> > >>
> > >
> > >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/60949b81/attachment.html>