Reconciling names

Jirka Tomasek jtomasek at redhat.com
Wed Oct 24 14:12:01 UTC 2012


On 10/24/2012 03:34 PM, Jaromír Coufal wrote:
>
> 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
>

Regarding the previous comments I am inclined more to calling the 
Component Outline, the Image Blueprint, to match the AppForm Blueprint 
and Image. Although it seems that the Component Outline name is not 
being possible to change. I wouldn't like to get rid of the "Image" as 
it is a proper word for the term I think.

Nevertheless I am really glad that we are converging to common set of terms!

Jirka



More information about the aeolus-devel mailing list