[openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Doug Hellmann doug at doughellmann.com
Mon May 23 16:48:07 UTC 2016

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

> 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


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

More information about the OpenStack-dev mailing list