Open Stack

On 01/14/2013 02:10 AM, Thierry Carrez wrote:
> 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.

Agree. This is really important - and actually any failure in the
"attempt to build stuff with current requirements list" needs to be
fixed swiftly.

>> 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 ?

Because the general requirements would be the source of information for
the creation of the pypi mirror- which means that packages just flat
would not be available for the unittest or devstack jobs without being
listed there first. I believe it would protect us from that...