On 10/24/2012 08:29 AM, Angus Thomas wrote:
Component Outline – This name is preferred, primarily because of
familiarity to existing users of Cloud Engine.
Image – Nothing to see here. Let harmony reign.
So this has caused some confusion with "image" being the
non-provider-specific container that includes actual provider images
across the provider accounts. Perhaps we should use "component" here,
but keep TargetImage, ProviderImage, etc -- it might actually remove the
confusion that the "image" object isn't really a disk image of any sort.
Component outline defines what to build, Component is what the assembly
references, and Provider Image is what is actually launched on a provider.
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.
First of all, AppForm is definitely an improvement over Application. An
application is something I launch on the command line on my laptop -- or
something I install on my Android phone.
that said, it's still a bit confusing, since I keep thinking that an
AppForm is a Deployable/App blueprint rather than a Deployment/App. The
'form' in there sounds like we're dealing with something template-like.
So if it's possible to revise this in a somewhat clearer direction, that
would be nice. Still I like it better than 'Application', so I won't
raise any strong objections here (like I might if we were still going to
call it Application). Oh, also, I'd prefer it without the StudlyCaps --
but again I won't push the point.
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.
I still don't like this one at all. Everything is 'Cloud' Do other cloud
management applications use 'Cloud' to reference an abstract grouping of
resources that could be launched in a number of back end clouds? It's
more of a metacloud. How about "Cloud Environment" ? This distinguishes
it from the Katello environments, keeps the 'cloud' name alive, but
doesn't leave the user wondering which of the many definitions of
'Cloud' is at work here.
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.
This one is fine for me.
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.
Realm isn't great, but I think it's better than 'cluster'. The other
suggestion for 'destination' might be good -- the main thing is this is
here for the purpose of a more targeted location/destination for launching.
Resource Provider – Note the proposal to remove “Cloud” as a prefix
Actually, this is one of the few places where I think 'Cloud' was
appropriate. "Cloud Provider" is, I think, a fairly well-understood
term. "Resource Provider" makes me ask "what kind of resources are we
talking about here?" -- it's also a nice parallel with "Cloud
Environment" if we choose to use that above.
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
+1
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
