[openstack-dev] [all] the trouble with names

michael mccune msm at redhat.com
Fri Feb 5 14:18:16 UTC 2016


On 02/05/2016 07:56 AM, Chris Dent wrote:
> 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].
>

well said

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

i'm open to this, assuming we create a well defined process to keeping 
the names in order.

> 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
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list