Open Stack

Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100:
> 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

Yes, I'm aware of cases of each of those projects being used without
"the rest" of OpenStack. I used keystone like that to secure some
internal APIs myself.

> 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

It's the basis of much if not all of the DefCore trademark work.
So there are still some folks who don't like it, but it's an official
goal.

> 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.

Not quite. With the different trademark programs in place, the
stance is "if you're calling your X API 'OpenStack' it needs to run
our code and it needs to pass the interop tests for the related
capabilities." Each trademark program has a different list of
projects to which it applies.  So it's more prix fixe with an option
of the number of courses rather than a la carte (I may need lunch).

> 
> 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?)

The DefCore team is working to establish the definition, and has a
well-defined process for documenting and modifying the definition over
time.

Doug

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