Open Stack

On Tue, 2013-07-16 at 13:37 -0400, Monty Taylor wrote:
> 
> 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.

Awesome, thanks - I've had that on my TODO list for weeks.

It's probably a bit early about oslo.messaging, since nothing's using it
yet ... but no harm in having it in there.

Thanks again,
Mark.