Reconciling names

Jirka Tomasek jtomasek at redhat.com
Wed Oct 24 15:14:46 UTC 2012


On 10/24/2012 04:43 PM, 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.
> Thanks for doing this! As you say, the current situation is quite
> frustrating.
>
>> Component Outline – This name is preferred, primarily because of
>> familiarity to existing users of Cloud Engine.
> I still find "Image Template" much clearer. I was going to say that the
> situation would be much clearer if we took to calling Images
> "Components" as others have proposed. But why would we rename something
> clear ("Image") to something ambiguous ("Component")?
>
> If PM agrees with our use of "Image", might they be amenable to using
> "Image Outline"? (I don't love that name, honestly.)
>
>> Assembly – This is an instance of Cloud Engine proposing to change to
>> come back in line with Aeolus
> Interestingly, this is one of the few cases where I thought their name
> ("Component Blueprint") was clearer than ours, at least the "Blueprint"
> part. But I'm happy to converge on something!
>
>> AppForm Blueprint and AppForm – Cloud Engine is committed to
>> "AppForm". It is intended to be a distinctive term which encapsulates
>> the specific thing that Cloud Engine/Aeolus provides. It differs from
>> a “Cloudformations stack”, for example, by virtue of its
>> cross-provider capabilities. There's enough unique value here to
>> justify a distinctive name, which can be used in promotional work.
>> “Deployable” is a generic term which doesn't do justice to the
>> capabilities of our application.
>>
>> In short, Cloud Engine is going to use the term AppForm. The question
>> is whether the Aeolus community can adopt it too, in order to achieve
>> convergence.
> Are we allowed to use this name upstream, or is it in some way
> trademarked?
>
> I'm torn here. We call this a Deployment, which is bad because it's
> easily confused with "Deployable". And I really want for us to converge
> on one set of names. But I also really, really dislike "AppForm" as a
> name. But lacking anything better, maybe, just maybe, we should just run
> with this.
>
>> 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?
>
>> 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.
If I am getting this right, the Frontend Realm specifies either 
Provider(or group of Providers)
or specific Provider Realm (or group of Provider Realms) that 
constraints where
the Deployment is launched.

<imagination hat on>
     So the Frontend Realms could be called something like Destinations 
or Destination Constraints.
<imagination hat off>
>
>> 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
Note inline.

Jirka



More information about the aeolus-devel mailing list