On Fri, Feb 20, 2015 at 7:27 AM, Doug Hellmann <d...@doughellmann.com>
wrote:

>
>
> On Fri, Feb 20, 2015, at 06:06 AM, Sean Dague wrote:
> > On 02/20/2015 12:26 AM, Adam Gandelman wrote:
> > > Its more than just the naming.  In the original proposal,
> > > requirements.txt is the compiled list of all pinned deps (direct and
> > > transitive), while requirements.in <http://requirements.in> reflects
> > > what people will actually use.  Whatever is in requirements.txt affects
> > > the egg's requires.txt. Instead, we can keep requirements.txt unchanged
> > > and have it still be the canonical list of dependencies, while
> > > reqiurements.out/requirements.gate/requirements.whatever is an upstream
> > > utility we produce and use to keep things sane on our slaves.
> > >
> > > Maybe all we need is:
> > >
> > > * update the existing post-merge job on the requirements repo to
> produce
> > > a requirements.txt (as it does now) as well the compiled version.
> > >
> > > * modify devstack in some way with a toggle to have it process
> > > dependencies from the compiled version when necessary
> > >
> > > I'm not sure how the second bit jives with the existing devstack
> > > installation code, specifically with the libraries from git-or-master
> > > but we can probably add something to warm the system with dependencies
> > > from the compiled version prior to calling pip/setup.py/etc
> > > <http://setup.py/etc>
> >
> > It sounds like you are suggesting we take the tool we use to ensure that
> > all of OpenStack is installable together in a unified way, and change
> > it's installation so that it doesn't do that any more.
> >
> > Which I'm fine with.
> >
> > But if we are doing that we should just whole hog give up on the idea
> > that OpenStack can be run all together in a single environment, and just
> > double down on the devstack venv work instead.
>
> I don't disagree with your conclusion, but that's not how I read what he
> proposed. :-)
>
>
Sean was reading between the lines here. We are doing all this extra work
to make sure OpenStack can be run together in a single environment, but it
seems like more and more people are moving away from deploying with that
model anyway. Moving to this model would require a little more then just
installing everything in separate venvs.  We would need to make sure we
don't cap oslo libraries etc. in order to prevent conflicts inside a single
service. And we would still need a story around what to do with stable
branches, how do we make sure new libraries don't break stable branches --
which in turn can break master via grenade and other jobs.



> Joe wanted requirements.txt to be the pinned requirements computed from
> the list of all global requirements that work together. Pinning to a
> single version works in our gate, but makes installing everything else
> together *outside* of the gate harder because if the projects don't all
> sync all requirements changes pretty much at the same time they won't be
> compatible.
>
> Adam suggested leaving requirements.txt alone and creating a different
> list of pinned requirements that is *only* used in our gate. That way we
> still get the pinning for our gate, and the values are computed from the
> requirements used in the projects but they aren't propagated back out to
> the projects in a way that breaks their PyPI or distro packages.
>
> Another benefit of Adam's proposal is that we would only need to keep
> the list of pins in the global requirements repository, so we would have
> fewer tooling changes to make.
>
> Doug
>
> >
> >       -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to