[openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Monty Taylor mordred at inaugust.com
Wed Jul 10 23:41:28 UTC 2013



On 07/10/2013 06:07 PM, Dolph Mathews wrote:
> 
> On Wednesday, July 10, 2013, Sean Dague wrote:
> 
>     Yesterday in the very exciting run around to figure out why the gate
>     was broken, we realized something interesting. Because of the way
>     the gate process pip requirements (one project at a time), on a
>     current gate run we actually install and uninstall
>     python-keystoneclient 4 times in a normal run, flipping back and
>     forth from HEAD to 0.2.5.
> 
>     http://paste.openstack.org/__show/39880/
>     <http://paste.openstack.org/show/39880/> - shows what's going on
> 
>     The net of this means that if any of the projects specify a capped
>     client, it has the potential for preventing that client from being
>     tested in the gate. This is very possibly part of the reason we
>     ended up with a broken python-keystoneclient 0.3.0 released.
> 
> 
>     I think we need to get strict on projects and prevent them from
>     capping their client requirements. That will also put burden on
>     clients that they don't break backwards compatibility (which I think
>     was a goal regardless). However there is probably going to be a bit
>     of pain getting from where we are today, to this world.
> 
> 
> Thanks for investigating the underlying issue! I think the same
> policy should apply a bit further to any code we develop and consume
> ourselves as a community (oslo.config, etc). I have no doubt that's the
> standard we strive for, but it's all too easy to throw a cap into a
> requirements file and forget about it.

I agree. I think that we have the multi-project integrated gate and all
- and we test that trunk of all the server projects work with trunk of
all the other server projects - keeping the client projects working like
that too seems like an excellent idea - and actually the easiest way to
ensure that we do not break anything moving forward.



More information about the OpenStack-dev mailing list