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
