On 11/22/2013 06:55 PM, Mark Washenberger wrote: > > > > On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins > <robe...@robertcollins.net <mailto:robe...@robertcollins.net>> wrote: > > On 22 November 2013 22:31, Thierry Carrez <thie...@openstack.org > <mailto:thie...@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 <rbtcoll...@hp.com <mailto:rbtcoll...@hp.com>> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
