Reconciling names

Jaromír Coufal jcoufal at redhat.com
Wed Oct 24 13:34:50 UTC 2012


On 24.10.2012 15:14, Imre Farkas wrote:
> 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.
+1, there is no connection in names between those two now. There should 
be Image (Template) or Component (Template).

>
>> 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".
+1, if something is template/outline/blueprint (standing for very 
similar concept) it doesn't make much sense for me to name each with 
different terms.

Regarding AppForm - if PM insists on this name, because of being part of 
branding, I would vote (in sake of consistency between 
downstream/upstream names) to try to keep it the same in Aeolus, I hope 
that community can/will adapt to that easily.

>
>> 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
>
>
I know, that it's hard to match all requirements. I am happy that 
unification of names moved forward and I believe, that in the end it 
would be valuable for us - thanks for this job.

-- Jarda

-- 
Jaromír Coufal

Interaction Designer
Red Hat Czech s.r.o.

Mobile: +420 724 595 508
E-mail: jcoufal at redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno




More information about the aeolus-devel mailing list