Open Stack

On 11/22/2013 06:55 PM, Mark Washenberger wrote:
> 
> 
> 
> On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins
> <robertc at robertcollins.net <mailto:robertc at robertcollins.net>> wrote:
> 
>     On 22 November 2013 22:31, 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.
> 
>     Huh. There are two different directions we use the client in.
> 
>     Client install -> cloud API (of arbitrary version A)
> 
>     Server install (of arbitrary version B) using the Python library ->
>     cloud API (version B)
> 
>     From a gating perspective I think we want to check
>     that:
>      - we can use the client against some set of cloud versions A
>      - that some set of version B where servers running cloud version B
>     can use the client against cloud version B
> 
>     But today we don't test against ancient versions of A or B.
> 
>     If we were to add tests for such scenarios, I'd strongly argue that we
>     only add then for case A. Where we are using the client lib in an
>     installed cloud, we don't need to test that it can still be used
>     against pre-diablo etc: such installed clouds can keep using the old
>     client lib.
> 
> 
> I'm afraid that if a critical bug is found in the old client lib, the
> current path for fixing it is to ask people to update to the latest
> client version, even internally to their old cloud. So would that cause
> a branch for backporting fixes?

The plan is that the current client libs should always be installable.
So we would not (and never have) make a branch for backporting fixes.

> FWIW, I don't think the changes glanceclient needs in v1 will break the
> 'B' case above. But it does raise a question--if they did, would it be
> sufficient to backport a change to adapt old supported stable B versions
> of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO
> is okay. 

I'm not sure I follow all the pronouns. Could you re-state this again, I
think I know what you're asking, but I'd like to be sure.

> 
>     So assuming you agree with that assertion, where do we need a branch
>     here?
> 
>     -Rob
> 
>     --
>     Robert Collins <rbtcollins at hp.com <mailto:rbtcollins at hp.com>>
>     Distinguished Technologist
>     HP Converged Cloud
> 
>     _______________________________________________
>     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
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>