Reconciling names

Scott Seago sseago at redhat.com
Wed Oct 24 15:46:53 UTC 2012


On 10/24/2012 11:36 AM, Hugh Brock wrote:
> 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?
With or without a bungee cord attached?


> 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
>
So in a way I'm less opposed to this than I was originally. I'm still 
concerned that the term 'cloud' alone might be confusing. Especially 
since, when at one point we were deciding how we'd map all this stuff to 
deltacloud, at the time we thought that pools/zones were the thing that 
mapped to a "front end" provider.

How about "Cloud environment" -- it seems to encapsulate most of what 
we're saying is good about 'cloud' -- but with the additional notion 
that these cloud environments differ in how they attach to physical 
clouds, their intended purpose (i.e. what images are available), etc. 
Especially since our intended use of the PoolFamily/Environment/Cloud 
concept was for things like separating "development" from "production", etc.

Scott



More information about the aeolus-devel mailing list