Open Stack

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+os at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev