[openstack-dev] [all][pbr] splitting our deployment vs install dependencies
robertc at robertcollins.net
Wed Apr 15 21:49:50 UTC 2015
On 15 April 2015 at 09:33, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> On Tue, Apr 14, 2015 at 2:36 AM, Thierry Carrez <thierry at openstack.org>
>> Robert Collins wrote:
>> > On 13 April 2015 at 22:04, Thierry Carrez <thierry at openstack.org> wrote:
>> >> How does this proposal affect stable branches ? In order to keep the
>> >> breakage there under control, we now have stable branches for all the
>> >> OpenStack libraries and cap accordingly. We planned to cap all other
>> >> libraries to "the version that was there when the stable branch was
>> >> cut". Where would we do those cappings in the new world order ? In
>> >> install_requires ? Or should we not do that anymore ?
>> >> 
>> >> http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
>> > I don't think there's a hard and fast answer here. Whats proposed
>> > there should work fine.
>> > [...]
>> > tl;dr - I dunno :)
> This is the part of the puzzle I am the most interested in. Making sure
> stable branches don't break out from underneath us forcing us to go into
> fire fighting mode.
I think this is very important too. The spec that James linked to
https://review.openstack.org/#/c/161047/ seems broadly to be heading
in the right direction to me - my -1 on it is because the described
failure mode is very solvable vs e.g. failure modes where dependencies
release broken stuff.
It is in short 'make a fully specified requirements list and use that
via pip -r in stable branch gate jobs'. I think thats entirely sane
(and have been discussing that in various places for a while :)).
*this* thread is about making install_requires, which we currently
source from requirements.txt, be sourced separately (from setup.cfg)
and then we don't need per-repo requirements.txts, which will align us
with the broader ecosystem as far as the definition of
We *do* have uses for fully specified things, and one of them is 'what
worked in that test run', which is what the etherpad is intended to
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev