I have the benefit here of being a beginner to openstack and having experienced AWS as a user. I think that the current "nova", "cinder" etc naming was confusing to me at first, but that it's a needed stumbling block for devs and deployers/ops to be precise.
However, for end-users, probably mostly in a GUI, you need to be smart about labels/names. Amazon currently uses a hybrid approach. They call 'compute' "ec2", but in the UI, the top dashboard explain all user-accessible services with both of the names and a short description. Basically, I think you keep the naming as is, and focus on clarification in the UI. - Nick Yeates > On Feb 5, 2016, at 7:56 AM, Chris Dent <cdent...@anticdent.org> 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]. > > 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 (╯°□°)╯︵┻━┻ 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 __________________________________________________________________________ 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
