On Jun 4, 2015 8:57 AM, "Monty Taylor" <mord...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev