Reconciling names

Imre Farkas ifarkas at redhat.com
Wed Oct 24 13:14:14 UTC 2012


On 10/24/2012 02:29 PM, Angus Thomas wrote:
> 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.

If we are renaming Image Template to Component Outline, we should rename 
Image to Component accordingly. Just to express their connection.


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

I would vote to use the same word for "Template" both for AppForm 
"Template" which is the Deployable and for Component "Template" which is 
the Image Template. So either we should use "AppForm/Component Outline" 
or AppForm/Component Blueprint".


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

These above are just my recommendations, I don't stick to them. For me 
the most important is to have same names in product and upstream.

Imre





More information about the aeolus-devel mailing list