Open Stack

Monty Taylor wrote:
> Step 0: Re-sync the contents of the files with the new state of reality
> Step 1: Drive updates to the OpenStack PyPI mirror from the requirements
> repo
> Step 2: Configure the Jenkins slaves to only talk to the PyPI mirror for pip
> Step 3: Add a step to the pypi mirror creation that pulls packages fresh
> from requirements into a new proposed state of the PyPI mirror, then
> tests all of the projects against that mirror and only promotes new
> packages into if those tests pass.

We also need to make sure that we react to a test fail in that area, as
I suppose we'll have to address the situation at some point.

> That's it. Done.
> 
> If we do through step 2, it means that before someone can add a new
> requirement to a project, it would have to go into
> openstack/requirements.

That would certainly simplify the job of packagers, who could subscribe
to changes in that repo and throw their weight in the discussion when a
new dep is proposed.

> If we do step 3, it'll trap for things like the
> sqlalchemy 0.8 upgrade issue. It also, as an approach, doesn't enforce
> that projects have to upgrade at any point, because previous versions of
> things will still be in our mirror (we don't purge it)

I'm not sure I understand. How does the general requirements work with
the per-project requirements ? Would this approach have protected us
from the recent setuptools upgrade issue ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack