Open Stack

Excerpts from Hayes, Graham's message of 2016-04-18 13:24:40 +0000:
> On 18/04/2016 13:51, Sean Dague wrote:
> > On 04/18/2016 08:22 AM, Chris Dent wrote:
> >> On Mon, 18 Apr 2016, Sean Dague wrote:
> >>
> >>> So if you have strong feelings and ideas, why not get them out in email
> >>> now? That will help in the framing of the conversation.
> >>
> >> I won't be at summit and I feel pretty strongly about this topic, so
> >> I'll throw out my comments:
> >>
> >> I agree with the basic premise: In the big tent universe co-
> >> installability is holding us back and is a huge cost in terms of spent
> >> energy. In a world where service isolation is desirable and common
> >> (whether by virtualenv, containers, different hosts, etc) targeting an
> >> all-in-one install seems only to serve the purposes of all-in-one rpm-
> >> or deb-based installations.
> >>
> >> Many (most?) people won't be doing those kinds of installations. If all-in-
> >> one installations are important to the rpm- and deb- based distributions
> >> then _they_ should be resolving the dependency issues local to their own
> >> infrastructure (or realizing that it is too painful and start
> >> containerizing or otherwise as well).
> >>
> >> I think making these changes will help to improve and strengthen the
> >> boundaries and contracts between services. If not technically then
> >> at least socially, in the sense that the negotiations that people
> >> make to get things to work are about what actually matters in their
> >> services, not unwinding python dependencies and the like.
> >>
> >> A lot of the basics of getting this to work are already in place in
> >> devstack. One challenge I've run into the past is when devstack
> >> plugin A has made an assumption about having access to a python
> >> script provided by devstack plugin B, but it's not on $PATH or its
> >> dependencies are not in the site-packages visible to the current
> >> context. The solution here is to use full paths _into_ virtenvs.
> >
> > As Chris said, doing virtualenvs on the Devstack side for services is
> > pretty much there. The team looked at doing this last year, then stopped
> > due to operator feedback.
> >
> > One of the things that gets a little weird (when using devstack for
> > development) is if you actually want to see the impact of library
> > changes on the environment. As you'll need to make sure you loop and
> > install those libraries into every venv where they are used. This
> > forward reference doesn't really exist. So some tooling there will be
> > needed.
> >
> > Middleware that's pushed from one project into another (like Ceilometer
> > -> Swift) is also a funny edge case that I think get funnier here.
> >
> > Those are mostly implementation details, that probably have work
> > arounds, but would need people on them.
> >
> >
> >  From a strategic perspective this would basically make traditional Linux
> > Packaging of OpenStack a lot harder. That might be the right call,
> > because traditional Linux Packaging definitely suffers from the fact
> > that everything on a host needs to be upgraded at the same time. For
> > large installs of OpenStack (especially public cloud cases) traditional
> > packages are definitely less used.
> >
> > However Linux Packaging is how a lot of people get exposed to software.
> > The power of onboarding with apt-get / yum install is a big one.
> >
> > I've been through the ups and downs of both approaches so many times now
> > in my own head, I no longer have a strong preference beyond the fact
> > that we do one approach today, and doing a different one is effort to
> > make the transition.
> >
> >     -Sean
> >
> 
> It is also worth noting that according to the OpenStack User Survey [0]
> 56% of deployments use "Unmodifed packages from the operating system".
> 
> Granted it was a small sample size (302 responses to that question)
> but it is worth keeping this in mind as we talk about moving the burden
> to packagers.

To be clear, "Moving the burden to packagers" is not the only option
available to us. I've proposed one option for eliminating the issue,
which has some benefits for us upstream but obviously introduces
some other issues we would need to resolve. Another option is for
more people to get involved in managing the dependency list. Some
(most? all?) of those new people may come from distros, and sharing
the effort among them would make it easier than each of them doing
all of the work individually. Sort of like an open source project.

Doug

> 
> 0 - 
> https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf (page 
> 36)
>