Open Stack

On Thu, 4 Feb 2016, Sean Dague wrote:

> 2) Have a registry of "common" names.
>
> Upside, we can safely use common names everywhere and not fear collision
> down the road.

This is the only option presented thus far which meets the needs of
end users and also some of our stated goals about creating
interoperable OpenStack-based clouds.

It does, however, require some integration and orchestration between
TC, Service Catalog work, and API-WG guidelines.

> Downside, yet another contention point.

What's the issue with contention? Contention is one of several tools
that humans use to resolve disagreement and reached a shared
understanding of the problem space. Without shared understanding
in a community there's zero chance a community will create and work
towards shared goals. Because even if everyone is using the same
words for the goals, if they aren't using the same meanings, it's
all bunk.

When we, as a group, start to contend over terms and identifiers
that's just a signal that we don't really know what we're trying to
do and need to work at it. A lot of people, frustrated with all this
talk, will call it bikeshedding and then go off and do their own
thing, potentially not in concert with other people's goals. Making
all that talk is sometimes necessary if we want to be headed in the
same direction[1].

The economics of our situation often make that kind of cross-project
noodling challenging. As a group of open source devs we likely need
to keep our patrons clearly aware of the value and amount of what
some would call overhead.

It is not overhead. It's a major part of the work.

The big tent, in some sense, has been an invitation to allow people
to work on a more diverse set of goals. At the edge this is
beneficial as it means more useful stuff, but it has diffused
understanding of what "OpenStack" is. For consumers of OpenStack (and
for devs who are primarily concerned with making a thing called
OpenStack that is useful for those consumers) there needs to be a
thing which is OpenStack and that thing needs to be consistent and
coherent. And limited[2].

A tool we have at our disposal for creating that consistency is the
service catalog and specifically the service catalog types.

Some will argue that this will lead to people contending over who
should occupy a type, as if that were a bad thing. It is not. Having
that discussion will help identify the flaws in the proposed
occupiers and keep the discussion of "what are we" alive and
healthy[3].

> A registry would clearly be under TC administration, though all the
> heavy lifting might be handed over to the API working group. I still
> imagine collision around some areas might be contentious.

I'm happy for the API-wg to handle some of this if mike and Everett
are as well. Making it work well will require everybody plays well
with the service catalog too[4]

The biggest challenge I predict is when we need to change things, as
we inevitably will. Many currently hold dear that we cannot impose
change upon the existing user base. Sometimes you do and really it's
not that much of a big deal compared to the pain of running
OpenStack in the first place.

[1] It's perfectly okay for tools to not head in the same
direction, especially if they can be consumed as independent
libraries or services and are not embedded in the world of
OpenStack. This is a good thing. There's far too much stuff _in_
OpenStack that should just be _used by_ OpenStack (or used by
OpenStack users).

[2] Yes, this means we need to have an opinion about what OpenStack
is and build that opinion into the system. That's good. OpenStack is
insufficiently generic to be unopinionated. Let's just get over
that.

[3] At the moment it appears that much of the time the goal of
OpenStack is to keep the gate running. This is classic statism at
its worst. Straight out of the movie Brazil.

[4] http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html

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