Open Stack

On Mon, 23 May 2016, Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:
>> I don't think language does (or should) have anything to do with it.
>>
>> The question is whether or not the tool (whether service or
>> dependent library) is useful to and usable outside the openstack-stack.
>> For example gnocchi is useful to openstack but you can use it with other
>> stuff, therefore _not_ openstack. More controversially: swift can be
>> usefully used all by its lonesome: _not_ openstack.
>
> Add keystone, cinder, and ironic to that list.

Hmmm. You can, but would people want to (that is, would it be a sound
choice?)? Or _do_ people? Maybe that's the distinction? As far as I
understand things, it's not unusual for standalone swift
installations to exist and it's something of an openstack joke that
there are "lots of rules about how things are done, but swift is
special". Something like gnocchi was designed from the outset to be
separable.

I don't really know. I'm firmly in the camp that OpenStack needs to
be smaller and more tightly focused if a unitary thing called OpenStack
expects to be any good. So I'm curious about and interested in
strategies for figuring out where the boundaries are.

So that, of course, leads back to the original question: Is OpenStack
supposed to be a unitary.

If it's _not_, they yes, we need some fairly arbitrary (as in, it's
okay if we pull them out of thin air without relation to the quality
of the product, because there is no product!) but concrete guidelines
that delineate in or out. We can just choose to choose them.

> As you say, there are a lot of good reasons to strive for loose
> coupling between components. On the other hand, whether or not an
> individual component can or should be used by itself isn't a
> sufficient line when we're talking about the nature of OpenStack
> as a whole, especially if we want interoperability between deployments.

If we want interoperability between deployments (is that yet
universally agreed?) then optionality is a useful guideline for
whether something is OpenStack[1] or not. If it's optional, then it
can't be part of OpenStack because if one install has it and another
does not, then interoperability is shot.

So that seems like a good second question: Do we all agree that the
thing called OpenStack at cloud A is the same thing as OpenStack
at cloud B?

(There's plenty of talk about this concept, but I'm pretty sure
there isn't agreement. If we're not working towards real agreement,
and we're not going to follow that agreement if we ever reach it,
what are we doing?)

[1] Being useful-to or usable-by OpenStack is a whole 'nother deal.

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent