On Fri, Nov 22, 2013 at 6:28 PM, Monty Taylor <mord...@inaugust.com> wrote:
> > > 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. > Yes. I think wires are a bit crossed here, but you and I agree. It seemed to me that Robert was suggesting that old clouds can internally keep using old versions of client libs. Which seems wrong since we don't do backports, so old clouds using old libs would never get security updates. > > > 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. > Sorry for being so vague. I'll try to be specific. Branch nova/stable/folsom depends on python-glanceclient/master. Suppose we find that nova/stable/folsom testing is broken when we stage (hopefully before merging) the breaking changes that are part of the python-glanceclient v1.0.0 release. Would it be acceptable in this case to have a compatibility patch to nova/stable/folsom? Or will the only option be to modify the python-glanceclient patch to maintain compatibility? Thanks!
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
