Open Stack

On Wed, 17 Feb 2016, Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +0000:
>> A reason _I_[1] think we need to limit things is because from the
>> outside OpenStack doesn't really look like anything that you can put
>> a short description on. It's more murky than that and it is hard to
>> experience positive progress in a fog. Many people react to this fog
>> by focusing on their specific project rather than OpenStack at
>> large: At least there they can see their impact.
>
> I've never understood this argument. OpenStack is a community
> creating a collection of tools for building clouds. Each part
> implements a different set of features, and you only need the parts
> for the features you want.  In that respect, it's no different from
> a Linux distro. You need a few core pieces (kernel, init, etc.),
> and you install the other parts based on your use case (hardware
> drivers, $SHELL, $GUI, etc.).

Ah. I think this gets to the heart of the matter. "OpenStack is a
[...] collection of tools for building clouds" is not really how I
think about it, so perhaps that's where I experience a problem. I
wonder how many people feel the way you do and how many people feel
more like I do, which is: I want OpenStack to be a thing that I, as
an individual without the help of a "vendor", can use to deploy a
cloud (that is easy for me and my colleagues to use) if I happen to
have >1 (or even just 1) pieces of baremetal lying around.

It's that "vendor" part that is the rub and to me starts bringing us
back into the spirit of "open core" that started the original
thread. If I need a _vendor_ to make use of the main features of
OpenStack then good golly that makes me want to cry, and want to fix
it.

To fix it, you're right, it does need a greater sense of "product"
"instead" of kit and the injection of opinions about reasonable
defaults and expectations of some reasonable degree of sameness
between different deployments of OpenStack. This is, in fact, what
much of the cross-project work that is happening now is trying to
accomplish.

>> This results in increasing the fog because cross-project concerns (which
>> help unify the vision and actuality that is OpenStack) get less
>> attention and the cycle deepens.
>
> I'm not sure cross-project issues are really any worse today than
> when I started working on OpenStack a few years ago. In fact, I think
> they're significantly better.

I agree it is much better but it can be better still with some
reasonable sense of us all working in a similar direction. The
addition of "users" to the mission is helpful.

> Architecturally and technically, project teams have always wanted
> to go their own way to some degree. Experimentation with different
> approaches and tools to address similar problems like that is good,
> and success has resulted in the adoption of more common tools like
> third-party WSGI frameworks, test tools, and patterns like the specs
> review process and multiple teams managing non-client libraries.
> So on a technical front we're doing better than the days where we
> all just copied code out of nova and modified it for our own purposes
> without looking back.

History is always full of weird stuff.

> We've had to change our approaches to dealing with the growth,
> and we still have a ways to go (much of it uphill), but I'm not
> prepared to say that we've failed to meet the challenge.

I fear that I gave you the wrong impression. I wasn't trying to imply
that we are doing poorly at cross project things, rather that if we had
fewer projects we could do even better at cross project things (as a
result of fewer combinations).

Also that growth should not be considered a good thing in and of itself.

-- 
Chris Dent               (¨s¡ã¡õ¡ã)¨s¦à©ß©¥©ß            http://anticdent.org/
freenode: cdent                                         tw: @anticdent