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.
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
