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