Open Stack

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

-- 
Sean Dague
http://dague.net