Open Stack

On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague <sean at dague.net> wrote:

> On 01/20/2015 08:15 PM, Robert Collins wrote:
> > On 21 January 2015 at 10:21, Clark Boylan <cboylan at sapwetik.org> wrote:
> > ...
> >> This ml thread came up in the TC meeting today and I am responding here
> >> to catch the thread up with the meeting. The soft update option is the
> >> suggested fix for non openstack projects that want to have most of their
> >> requirements managed by global requirements.
> >>
> >> For the project structure reform opening things up we should consider
> >> loosening the criteria to get on the list and make it primarily based on
> >> technical criteria such as py3k support, license compatibility, upstream
> >> support/activity, and so on (basically the current criteria with less of
> >> a focus on where the project comes from if it is otherwise healthy).
> >> Then individual projects would choose the subset they need to depend on.
> >> This model should be viable with different domains as well if we go that
> >> route.
> >>
> >> The following is not from the TC meeting but addressing other portions
> >> of this conversation:
> >>
> >> At least one concern with this option is that as the number of total
> >> requirements goes up is the difficulty in debugging installation
> >> conflicts becomes more difficult too. I have suggested that we could
> >> write tools to help with this. Install bisection based on pip logs for
> >> example, but these tools are still theoretical so I may be
> >> overestimating their usefulness.
> >>
> >> To address the community scaling aspect I think you push a lot of work
> >> back on deployers/users if we don't curate requirements for anything
> >> that ends up tagged as "production ready" (or whatever the equivalent
> >> tag becomes). Essentially we are saying "this doesn't scale for us so
> >> now you deal with the fallout. Have fun", which isn't very friendly to
> >> people consuming the software. We already have an absurd number of
> >> requirements and management of them has appeared to scale. I don't
> >> foresee my workload going up if we open up the list as suggested.
> >
> > Perhaps I missed something, but the initial request wasn't about
> > random packages, it was about other stackforge clients - these are
> > things in the ecosystem! I'm glad we have technical solutions, but it
> > just seems odd to me that adding them would ever have been
> > controversial.
>
> Well, I think Clark and I have different opinions of how much of a pain
> unwinding the requirements are, and how long these tend to leave the
> gate broken. I am happy to also put it in a "somebody elses problem
> field" for resolving the issues. :)
>
> Honestly, I think we're actually at a different point, where we need to
> stop assuming that the sane way to deal with python is to install it
> into system libraries, and just put every service in a venv and get rid
> of global requirements entirely. Global requirements was a scaling fix
> for getting to 10 coexisting projects. I don't think it actually works
> well with 50 ecosystem projects. Which is why I proposed the domains
> solution instead.
>
>
++ using per service virtual environments would help us avoid a whole class
of nasty issues. On the flip side doing this makes things harder for
distros to find a set of non-conflicting dependencies etc.


> > On the pip solver side, joe gordon was working on a thing to install a
> > fixed set of packages by bypassing the pip resolver... not sure how
> > thats progressing.
>
> I think if we are talking seriously about bypassing the pip resolver, we
> should step back and think about that fact. Because now we're producting
> a custom installation process that will produce an answer for us, which
> is completely different than any answer that anyone else is getting for
> how to get a coherent system.
>

Fully agreed, I am looking into avoiding pips dependency solver for stable
branches only right now. But using per service venvs would be even better.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150126/75a875f8/attachment.html>