Reconciling names

Hugh Brock hbrock at redhat.com
Wed Oct 24 15:36:49 UTC 2012


On Wed, Oct 24, 2012 at 10:43:53AM -0400, Matt Wagner wrote:
> On Wed, Oct 24, 2012 at 01:29:18PM +0100, Angus Thomas wrote:
> <snip>
> > I'm approaching this from the perspective of a member of the Aeolus
> > community. Because of my job, though, I'm in a position to talk
> > directly to product managers etc. associated with Cloud Engine, and
> > to move to an agreement. To that end, Hugh and I have already met
> > with the Cloud Engine product managers, persuaded them, if it was
> > necessary, that the disadvantages of the current situation are such
> > that we should all seek to resolve it, and established what their
> > position is on each of the current set of terms.
> 

[useful content snipped, apols]
> 
> > Cloud – “Environment” is difficult because that term already has a
> > specific meaning in Katello, which is different to the way that we're
> > currently using it. A Katello environment is essentially a set of
> > repositories of content. That doesn't map directly onto what we're
> > calling environments and, given the fact that Katello and Aeolus are
> > complimentary applications, we should avoid a concept/name collision.
> > 
> > From the point of view of users, Aeolus makes cloud resources
> > available. This is an encapsulation of those resources, hence Cloud.
> > 
> > Also, this is the term, they tell me, which is employed by other
> > widely used cloud infrastructure management applications, so it is
> > the term that a lot of potential users understand. Using it will make
> > adoption simpler.
> 
> I want to be careful here, because I don't really know how our
> real-world users think, and my thinking may be very different than
> theirs.
> 
> We have to change _something_, because we call this an Environment, the
> code still calls it a Pool Family, and downstream calls it a Cloud.
> 
> My problem with "Cloud" is... Well, actually, I have several.
> 
> One is that "cloud" is already overloaded and over-hyped. It's like
> calling things "green" -- it's gotten to the point where it really has
> no meaning. MS Office markets itself as being part of the cloud, for
> example. I have no clue what that even means. So we're adding this
> overused, ambiguous buzzword and expecting people take us seriously.
> 
> Another problem is that, within a narrower niche of tech-savvy
> sysadmins, "cloud" _does_ have a clearer meaning. It's cloud providers,
> like EC2 or Rackspace, or internal private "clouds". But that's now how
> we are using it, _even though we have that concept in our app_. We are
> instead using it to refer to a smaller grouping of things. So in
> CloudForms Cloud Engine, you can have Clouds that don't map up to the
> clouds you are using. How does that even make sense?
> 
> So we are hijacking an overused term, and not even using it in its
> sometimes-understood meaning. Personally, as a technical person, I would
> have a hard time taking seriously a product that misused the word
> "cloud" -- particularly one that was actually supposed to manage cloud
> resources.
> 
> As for the fact that everyone else abuses the word "cloud" -- as my
> mother used to say: if all your friends jumped off a bridge, would you?

OK, I'm going to try to mount a defense of "Cloud" here on the
merits. Wish me luck.

I'm sorry to have to admit it, but using "Cloud" for what we currenly
call "Pool Family" or "Environment" was actually my idea. So was Pool
Family, to be fair. The reason I had the idea at the time, and the
reasons I *still* think it fits, are as follows:

* Conductor, properly imagined, has a single primary mission, which is
  to provide administrators with a way to merge or synthesize provider
  clouds -- an EC2 account, a private RHEV instance, a private vSphere
  instance -- into a single entity.

(leave aside the fact that right now Conductor does a whole bunch of
other stuff, we need to fix that and it shouldn't enter into this
discussion)

* If we all do our jobs properly, the merged entity, with the various
  providers added and obscured by the Conductor mechanisms that serve
  that purpose, should be indistinguishable to an end-user from a
  compute cloud. In other words, I should be able to connect to
  Conductor and launch a thing in a Conductor Cloud, and that operation
  should be *not even a little bit different* from connecting to EC2 and
  launching that same thing.

* The only difference between such a merged entity and an Amazon cloud
  or an OpenStack cloud, is that you don't know in advance which
  provider cloud your instance is eventually going to wind up on. In my
  view though *this is precisely what a cloud is*. You don't know which
  rack or which machine in the us-east data center your instance is
  going to be on, and you don't *need* to know. If you do need to know
  whether your instance is running on EC2 or vSphere, then we're not
  doing our jobs right.

So, that's the rationale. Please feel free to tell me I'm all wet, and I
would welcome alternate suggestions for the name for this thing. If you
disagree with my understanding of the primary mission of Conductor, that
is also a discussion worth having, but by all means let's have it now so
we can settle it :).

Take care,
--Hugh

> > Resource Zone – This is the first of several instances where the
> > Cloud Engine product managers are proposing to drop the (over)use of
> > Cloud as a prefix.
> 
> Pool == Resource Zone. This can work for me.
> 
> > Frontend Realm/<Your name here> - This is open to good ideas. The
> > problems with “Frontend Realm” are that it doesn't help the user
> > understand purpose and, specifically, it doesn't make clear that this
> > is a collection of Provider Realms.
> 
> My understanding is that this was previously called a Cloud Resource
> Cluster in product?
> 
> I think the real problem, IMHO, is that a realm is something hard to
> understand or explain. So neither "Frontend Realm" nor "Cloud Resource
> Cluster" is something intuitive.
> 
> > Resource Provider – Note the proposal to remove “Cloud” as a prefix
> 
> Ironically, this is the one place we _shouldn't_ remove the "Cloud"
> label, IMHO. It's probably clear enough what a "Provider" is in the
> context of our app, but "Cloud Provider" seems unambiguous and
> widely-understood.
> 
> > Hardware Profile - Cloud Engine is proposing to change to come back
> > in line with Aeolus
> 
> This one is good news! This one is consistent with what Deltacloud uses,
> and HWP is an easy-to-understand name IMHO.
> 
> > Provider Realm - Cloud Engine is proposing to change to come back in
> > line with Aeolus
> 
> I'm honestly not sure what name they used here previously, but I think
> this is good news.
> 
> > p.s. I was tempted to title this mail "You say tomato..", but thought
> > better of it, since it didn't really strike the right tone. If you've
> > made it this far, though, you could probably do with some (mild)
> > amusement.
> 
> Heh, some humor definitely helps! :)
> 
> -- Matt

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list