<p dir="ltr">So we should have told the folks to so developing agent? (Not sure why you all think I'm talking about us) Maybe.</p>
<p dir="ltr">But anyway anyone deliberately ignores my points, so I'm done with this discussion.</p>
<div class="gmail_quote">04 июня 2015 г. 18:17 пользователь "Devananda van der Veen" <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
On Jun 4, 2015 8:57 AM, "Monty Taylor" <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>> wrote:<br>
><br>
> On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:<br>
> > On 06/04/2015 05:03 PM, Sean Dague wrote:<br>
> >> On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:<br>
> >>> On 06/04/2015 04:40 PM, Ruby Loo wrote:<br>
> >>>> Hi,<br>
> >>>><br>
> >>>> In Kilo, we introduced microversions but it seems to be a<br>
> >>>> work-in-progress. There is an effort now to add microversion into the<br>
> >>>> API-WG's guidelines, to provide a consistent way of using microversions<br>
> >>>> across OpenStack projects [1]. Specifically, in the context of this<br>
> >>>> email, there is a proposed guideline for when to bump the microversion<br>
> >>>> [2].<br>
> >>><br>
> >>> As I understand this guideline tells to bump microversion on every<br>
> >>> change which I strongly -1 as usual. Reason: it's bump for the sake of<br>
> >>> bump, without any direct benefit for users (no, API discoverability is<br>
> >>> not one, because microversion do not solve it).<br>
> >>><br>
> >>> I'll post the same comment to the guideline.<br>
> >><br>
> >> Backwards compatible API adds with no user signaling is a fallacy<br>
> >> because it assumes the arrow of time flows only one way.<br>
> >><br>
> >> If at version 1.5 you have a resource that is<br>
> >><br>
> >> foo {<br>
> >>    "bar": ...<br>
> >> }<br>
> >><br>
> >> And then you decide you want to add another attribute<br>
> >><br>
> >> foo {<br>
> >>    "bar": ...<br>
> >>    "baz": ...<br>
> >> }<br>
> >><br>
> >> And you don't bump the version, you'll get a set of users that use a<br>
> >> cloud with baz, and incorrectly assume that version 1.5 of the API means<br>
> >> that baz will always be there. Except, there are lots of clouds out<br>
> >> there, including ones that might be at the code commit before it was<br>
> >> added. Because there are lots of deploys in the world, your users can<br>
> >> effectively go back in time.<br>
> >><br>
> >> So now your API definition for version 1.5 is:<br>
> >><br>
> >> "foo, may or may not contain baz, and there is no way of you knowing if<br>
> >> it will until you try. good luck."<br>
> >><br>
> >> Which is pretty aweful.<br>
> ><br>
> > Which is not very different from your definition. "Version 1.5 contains<br>
> > feature xyz, unless it's disabled by the configuration or patched out<br>
> > downstream. Well, 1.4 can also contain the feature, if downstream<br>
> > backported it. So good luck again."<br>
> ><br>
> > If you allow to group features under one microversion, that becomes even<br>
> > worse - you can have deployment that got microversion only partially.<br>
> ><br>
> > For example, that's what I would call API discoverability:<br>
> ><br>
> >  $ ironic has-capability foobar<br>
> >  true<br>
> ><br>
> > and that's how it would play with versioning:<br>
> ><br>
> >  $ ironic --ironic-api-version 1.2 has-capability foobar<br>
> >  false<br>
> >  $ ironic --ironic-api-version 1.6 has-capability foobar<br>
> >  true<br>
> ><br>
> > On the contrary, the only thing that microversion tells me is that the<br>
> > server installation is based on a particular upstream commit.<br>
> ><br>
> > To me these are orthogonal problems, and I believe they should be solved<br>
> > differently. Our disagreement is due to seeing them as one problem.<br>
><br>
> We should stop doing this everywhere in OpenStack. It is the absolute<br>
> worst experience ever.<br>
><br>
> Stop allowing people to disable features with config. there is literally<br>
> no user on the face of the planet for whom this is a positive thing.<br>
><br>
> 1.5 should mean that your server has Set(A) of features. 1.6 should mean<br>
> Set(A+B) - etc. There should be NO VARIATION and any variation on that<br>
> should basically mean that the cloud in question is undeniably broken.<br>
><br>
> I understand that vendors and operators keep wanting to wank around with<br>
> their own narccisitic arrogance to "differentiate" from one another.<br>
><br>
> STOP IT<br>
><br>
> Seriously, it causes me GIANT amount of pain and quite honestly if I<br>
> wasn't tied to using OpenStack because I work on it, I would have given<br>
> up on it a long time ago because of evil stuff like this.<br>
><br>
> So, seriously - let's grow up and start telling people that they do not<br>
> get to pick and choose user-visible feature sets. If they have an unholy<br>
> obsession with a particular backend technology that does not allow a<br>
> public feature of the API to work, then they are deploying a broken<br>
> cloud and they need to fix it.<br>
></p>
<p dir="ltr">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:<br>
- vendor lock in<br>
- they stop using OpenStack<br>
And since avoiding single vendor lock in is important to them, well, really it has only one result.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> >><br>
> >> Looking at your comments in the WG repo you also seem to only be<br>
> >> considering projects shipped at Major release versions (Kilo, Liberty).<br>
> >> Which might be true of Red Hat's product policy, but it's not generally<br>
> >> true that all clouds are at a release boundary. Continous Deployment of<br>
> >> OpenStack has been a value from Day 1, and many public clouds are not<br>
> >> using releases, but are using arbitrary points off of master.<br>
> ><br>
> > I don't know why you decided I don't know it, but you're wrong.<br>
> ><br>
> >> A<br>
> >> microversion describes when a changes happens so that applications<br>
> >> writers have a very firm contract about what they are talking to.<br>
> ><br>
> > No, they don't. Too many things can modify behavior - see above.<br>
> ><br>
> >><br>
> >>     -Sean<br>
> >><br>
> ><br>
> ></p>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>