[openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
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/> - 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