Open Stack

On 07/16/2013 11:42 AM, Doug Hellmann wrote:
> 
> 
> 
> On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin <markmc at redhat.com
> <mailto:markmc at redhat.com>> wrote:
> 
>     On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote:
>     > On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor
>     <mordred at inaugust.com <mailto:mordred at inaugust.com>> wrote:
>     >
>     > > I was looking in to dependency processing as part of some pbr
>     change,
>     > > which got me to look at the way we're doing oslo-config dev
>     requirements
>     > > again. To start, this email is not about causing us to change
>     what we're
>     > > doing, only possibly the mechanics of what we put in the
>     > > requirements.txt file- or to get a more specific example of what
>     we're
>     > > solving so that I can make a test case for it and ensure we're
>     handling
>     > > it properly.
>     > >
>     > > Currently, we have this:
>     > >
>     > > -f
>     > >
>     > >
>     http://tarballs..openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2..0a3
>     <http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3>
>     > > oslo.config>=1.2.0a3
>     > >
>     > > As the way to specify to install >- 1.2.0a3 of oslo.config. I
>     believe
>     > > this construct has grown in response to a sequence of issues,
>     but it's
>     > > complex and fragile, so I'd like to explore what's going on.
>     > >
>     > > The simplest answer would be simply to replace it with:
>     > >
>     > > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz
>     > >
>     > > which will quite happily cause pip to install the contents of that
>     > > tarball. It does not declare a version, but it's not necessary to,
>     > > because the tarball has only one version that it is. Is there a
>     problem
>     > > we have identified where the wrong thing is happening?
>     > >
>     >
>     > > I've tested that I get the right thing in a virtualenv if I make
>     that
>     > > change from pip installing a tarball, pip installing the
>     requirements
>     > > directly and python setup.py install. Is there anything I'm missing?
>     > >
>     > > Monty
>     > >
>     >
>     >
>     > Without the version specifier, we are relying on all projects to
>     install
>     > the right version from that tarball link when we run devstack, but
>     we have
>     > no guarantee that they are moving to new releases in lockstep.
> 
>     Yep, that's it. The thing to test would be if some projects have the
>     1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends
>     on an API that's new in 1.2.0a3.
> 
> 
> It's worse than that. What gets installed will depend on the order
> devstack installs the projects and what their respective requirements
> lists say. It is possible to end up with compatible source code
> installed, but with a version number that setuptools thinks is not
> compatible based on projects' requirements. In that case, setuptools may
> not let us load plugins, so services will start but not actually work.

Thank you. This is what I needed here.

BTW - I put this up:

https://review.openstack.org/#/c/35705/

To take a stab at installing our global requirements list first, and
then installing our projects in that environment. I also just made:

https://review.openstack.org/#/c/37295/

Which would add oslo.config and oslo.messaging as git repos to the
devstack system, so that we can track trunk like we do with the other
projects.

Monty