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

Mark McLoughlin markmc at redhat.com
Thu Jul 11 11:12:12 UTC 2013

On Wed, 2013-07-10 at 17:07 -0500, 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 don't think we've ever capped oslo.config anywhere. Got a pointer to
what triggered that concern?

We should/could be capping oslo.config like this:


because the API stability commitment is that we won't break the API
without bumping the release number to 2.0. I don't anticipate doing 2.0
soon/ever, so I've never pushed ahead with that capping.


More information about the OpenStack-dev mailing list