On 11/11/2011 02:25 PM, Matt Wagner wrote:
On Fri, Nov 11, 2011 at 05:48:47PM +0000, Angus Thomas wrote:
> There's been a lot of discussion recently about the best way to name
> the components that our users interact with.
>
> We have sought to arrive at a set of names with which are:
>
> - Descriptive and intuitive
> - Internally consistent
> - Consistent with the names used by similar applications which users
> might be familiar with
Amen! Are the names below consistent with what Katello is calling
things?
My initial reaction is that each and every one of these names is
significantly more confusing and less accurate than what we're using now.
> So, here's the list:
Is this a brainstormed list meant to start discussion, or is this
intended as a settled list coming down from on high? I'm hoping (and
assuming, for the purposes of my reply below) that it's the former, but
it doesn't quite sound like it. :-\
> Image template -> Component Outline
What's wrong with template?
Component is a lot more vague than Image, so
it leaves me wondering if it's an outline for a whole instance, part of
an instance, a cluster of instances, etc.
> Assembly -> Component Blueprint
> Deployable -> Application Blueprint
> Deployment -> Application
Application is a particularly poor choice here --
since Application is
also very commonly used to describe individual bits of functionality
installed in a single instance. After all, I've got dozens of
applications installed on my phone even. In a single deployment, many
applications may be installed on each instance.
'blueprint' isn't so horrible, but compared with 'outline', the
differences in what we intend aren't so clear from the differences in
the meanings of the chosen English words.
This is a lot to wrap my head around, but I think this much is
probably
for the better. I'm glad that the confusingly-similar "Deployable" and
"Deployment" names are on their way out.
If we have Component Outlines and Component Blueprints, what is just a
"Component"?
> Pool Family/Environment -> Cloud
This one is tough to swallow. I can see the logic in it -- you might
have a "Development" Environment or a "Finance Department" Pool
Family,
and it would make some amount of sense to say "I launched another
instance in the Finance Department cloud."
Environment is a reasonably accurate name for this. Cloud seems less so
-- especially since it will be confused with the providers -- "but wait,
my dev boxes are in 3 different clouds, why are you calling 'dev' a cloud?"
Pool -> Cloud Resource Zone
This isn't so bad -- but
I'd rather have a zone within an environment
than a zone within a cloud.
User Defined Realm -> Cloud Resource Cluster
Why cluster? This can map to one or
more providers, or one or more
provider realms, or both. The reason we call it realm is that we intend
to expose all of this via the deltacloud API, which uses realm to
describe it. In addition, Cluster has a fairly specific meaning that
implies very close association, redundancy, failover, etc. But this
"Cluster" may span multiple providers and include instances unrelated to
each other. The term is way too confusing used in this way.
Provider -> Cloud Resource Provider
Hardware Profile -> Cloud Resource Profile
Profile is too generic without some
notion of what we intend by it.
Specifically we're referring to instance sizing. We call it Hardware
Profile because, again, that's the deltacloud concept that we're
exposing. But if we can't use that, we'd better at least indicate that
this refers to per-instance resource allotment, instance sizing, or
something similar. Otherwise this becomes yet another term whose common
English understanding fails to communicate anything relevant to what we
mean by it here.
Scott