Open Stack

On 2014-04-09 10:49:20 -0700 (-0700), Clint Byrum wrote:
> Excerpts from Ruslan Kamaldinov's message of 2014-04-09 10:24:48 -0700:
> > But, other concerns were expressed in the past. Let me quote
> > Jeremy Stanley (from https://review.openstack.org/#/c/66884/):
> > > This will need to be maintained in Ubuntu (and backported to
> > > 12.04 in Ubuntu Cloud Archive or if necessary a PPA managed by
> > > the same package maintenance team taking care of it in later
> > > Ubuntu releases). We don't install test requirements
> > > system-wide on our long-running test slaves unless we can be
> > > assured of security support from the Linux distribution
> > > vendor.
[...]

Keep in mind that at the time I said that, we had not completed our
transition to all single-use Jenkins slaves managed by nodepool. My
analysis of the risk is thus shifted slightly now. I'm not opposed
to official OpenStack projects needing arbitrary files cached
locally on our nodepool images so that they can make use of them on
demand without incurring download-related stability penalties (we
already do this for a lot of the packages and other bits DevStack
needs, for example test images). I'm also not worried by cached
packages on the images which are used by some jobs for official
projects without being installed by default. We've now got the
ability for some jobs to opt out of sudo restrictions, and so they
could in theory install these cached packages immediately prior to
running their own tests. I mainly just want to make sure we're not
preinstalling packages we can't trust unconditionally on all test
systems.

> This is a huge philosophical question for OpenStack in general. Do
> we want to recommend things that we won't, ourselves, use in our
> infrastructure?
[...]
> Basically the support model of the distro isn't compatible with
> the support model of these databases.
[...]

This is where most of my current concerns with the situation are.
OpenStack is something run on servers, which operators are almost
always going to want under some sort of stable package management
from a distribution with a trust chain and security support. I think
we should be testing things in the sorts of ways we expect them to
be deployed in production by operators, whenever possible.

The current development communities around these databases don't
sound like they've yet reached the maturity where they're turning
out stable, long-term-supported and modularized software which would
be commonly found in those sorts of environments (nor would I feel
comfortable recommending them as a production solution until that
changes). This is not meant in a disparaging way--it's common that
projects have a high rate of churn early on as larger design
decisions are made, APIs are still being fleshed out, solutions are
tried and deemed untenable, et cetera and forward momentum trumps
deployability/stability/maintainability.

And to some degree, yes, this is the pot calling the kettle black
since OpenStack itself can't seem to muster enough developers
interested in keeping stable release branches maintained and
testable for more than ~9 months before we're forced to EOL them due
to neglect. The irony is not lost on me. ;)
-- 
Jeremy Stanley