Open Stack

On 11/22/2013 09:57 AM, Dolph Mathews wrote:
> 
> On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
> 
>     Robert Collins wrote:
>     > I don't understand why branches would be needed here *if* the breaking
>     > changes don't impact any supported release of OpenStack.
> 
>     Right -- the trick is what does "supported" mean in that case.
> 
>     When the client libraries were first established as separate
>     deliverables, they came up with a blanket statement that the latest
>     version could always be used with *any* version of openstack you may
>     have. The idea being, if some public cloud was still stuck in pre-diablo
>     times, you could still use the same library to address both this public
>     cloud and the one which was 2 weeks behind Havana HEAD.
> 
> 
> I'm curious about the historical circumstance of this requirement --
> were the services supported "master, minus two releases" at the time?
> 
> We're not testing more than two stable releases against the latest
> clients in CI today, so I find it odd that we still bother with this
> claim, without demonstrating that it's true.

The design of this comes from an end-user perspective.

If Alice wants to use a cloud, Bob, Alice should download the current
python-glanceclient library, provide it with her credentials, and it
should work, regardless of what version of OpenStack Bob's operator
happens to be running.

The reason for the above is that any other approach is a TERRIBLE end
user experience. (As a person who currently is involved with running a
scalable cloud application on two OpenStack clouds that are wildly
different versions, I can tell you, needing to install different client
library versions to talk to them would be madness.

That's about outbound API versions though. That means that master
*client must always be able to speak to every extant API version.

This question is actually about python API consumption, and when we made
the policy, we did discuss that were a breaking change to be made in the
Python API, clearly the semver Major version should be bumped.

Unfortunately for this conversation, we stopped with Brian Waldon's
assertion of the major version bump and did not design a system to
handle it. We do not currently have the machinery to handle it. At the
very latest, we would need to design a modification to how zuul and
devstack-gate construct collections of changesets.

That said - we need to think about the questions raised above in terms
of support of python API. But, more importantly, we should really think
long and hard about breaking the python API, even with a major version
bump, because no matter how you do it, it's disruptive to library consumers.

>     --
>     Thierry Carrez (ttx)
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> 
> -Dolph
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>