Reconciling names

Angus Thomas athomas at redhat.com
Wed Oct 24 12:29:18 UTC 2012


As many, though probably not all, participants in the Aeolus community 
will be aware, it has been the case for some time that Red Hat's Cloud 
Engine product, which is a “downstream”, supported version of Aeolus, 
uses several terms which are different from the terms used by Aeolus.

Rather than attempt to examine the past, I want us, as far as possible, 
to reconcile those two set of names. Several members of the Aeolus 
community are directly aware of the pain that the current situation 
causes, but there are a few points which are with articulating:

- Users of Cloud Engine, as well as the Red Hat staff who support it 
etc. are using terminology which doesn't apply upstream, putting a 
barrier between the Aeolus project and a good number of the users of our 
software.
- Similarly, we, in the Aeolus project, are writing blog posts etc. 
which will make little sense to all the users who come to Aeolus through 
the productised Cloud Engine version.
- As part of the productisation process, Red Hat translates all the 
strings in Conductor into nine different languages.[1] If the use of 
terms could be reconciled, Aeolus Conductor would immediately support 
nine languages, rather than supporting one.
- Not a problem for the Aeolus project, per se, but the work required to 
maintain a separate set of terms for the Cloud Engine product is tedious 
and error-prone and falls entirely on people who are key contributors to 
Aeolus, and whose time could be better spent.

So, lots of reasons, for the benefit of all concerned, why it would be 
good to reconcile the sets of names, or, at least, to minimise the gap.

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.

[2] is a list of the current Aeolus and Cloud Engine terms, and anl set 
of proposals for a reconciled set. To be clear, the “Future” column is 
not a final set of names. Aeolus is free to use whatever names the 
community wishes, but we risk continuing to incur the costs listed earlier.

As the list shows, the Cloud Engine product managers have listened to 
our feedback on their names, and have sought, in several cases, to move 
towards us.


Some comments on specific names:

Component Outline – This name is preferred, primarily because of 
familiarity to existing users of Cloud Engine.


Image – Nothing to see here. Let harmony reign.


Assembly – This is an instance of Cloud Engine proposing to change to 
come back in line with Aeolus


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.


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.


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.


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.


Resource Provider – Note the proposal to remove “Cloud” as a prefix


Hardware Profile - Cloud Engine is proposing to change to come back in 
line with Aeolus


Provider Realm - Cloud Engine is proposing to change to come back in 
line with Aeolus


Instance - – Nothing to see here. Let harmony reign.


Catalog - – Nothing to see here. Let harmony reign.


Config Server - – Nothing to see here. Let harmony reign.



So, thoughts, please. There's an opportunity here to solve a problem.



Angus

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.


[1] https://translate.zanata.org/zanata/project/view/aeolus-conductor
[2] http://dl.dropbox.com/u/5095754/Conductor_Names_v1.pdf




More information about the aeolus-devel mailing list