On 11/11/2011 04:48 PM, Hugh Brock wrote:
On Fri, Nov 11, 2011 at 04:15:59PM -0500, Matt Wagner wrote:
> In which I attempt to offer some possible alternatives:
>
> On Fri, Nov 11, 2011 at 02:58:47PM -0500, Scott Seago wrote:
>>>> 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.
>
> I don't understand the difference between an Outline and a Blueprint.
> Was the 'Template' term retired? I think I second Scott here; 'Image
> Template' is a good name.
>
>>>> Assembly -> Component Blueprint
>
> Do users see Assemblies anywhere in our app?
>
>>>> 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.
>
> To Scott's point, 'Application' might be better-received if not for
> iPhones and their 'app store'.
>
> If we think back to physical hardware, suppose I rent a rack in a data
> center and install four application servers, a load balancer, and a
> database. What do I have? A "rack" of servers? A "cluster" of
machines?
> A "stack"? Just servers? They do, presumably, power one application, but
> I wouldn't ever say "I'm driving over to the data center to upgrade the
> RAM on my application."
>
> I like the idea of renaming Deployables to a Whatever Template. (Or
> Blueprint, but can we agree to either use "Blueprint" everywhere or
> "Template" everywhere? I'm partial to Template, but don't feel
strongly
> either way.) The Deployable vs. Deployment thing was always a little
> confusing, and I think this would help avoid that.
>
>> '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.
>
> I still don't understand the difference between 'outline' and
> 'blueprint', but it might just be me. As I mentioned above, I think
> 'blueprint' and 'template' mean about the same thing. I don't
> particularly care which we use, but 'template' is already in use so we
> probably shouldn't change it without good reason.
OK, I should probably weigh in here in defense of some of these...
Bryan was very interested in choosing a name that would highlight the
progression the user goes through when building first a template and
then an assembly. We struggled with this for a long time and came up
with Component Outline and Component Blueprint, intending to highlight
the idea that these are the things you put together to build up your
n-tier Application.
The fact is that our image template is a long way from a template, in
the sense that it's not nearly that descriptive. You can write a
template that says "RHEL 6" and "httpd" and that's it -- the
resulting images can be different in almost every other respect,
depending on what OS we build for, when we build, and even who is
building. We settled on "Outline" because it seemed closer to what the
thing actually is.
For assemblies (which we're renaming "Component Blueprint"), I would
have preferred "System Blueprint" or "Machine Blueprint" just
because
that's a lot closer to what the thing actually is. We wound up
settling on "Component Blueprint" because "Component" was sort of
the
lowest-common-denominator term we could come up with that could
describe both the template and the assembly's role in the
application.
I know Scott doesn't like Application Blueprint, but I'm not as put
off by the potential confusion between iApps and cloudforms-style
n-tier apps -- I think especially when Katello is building this stuff
people will get what it is.
>>>> 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?"
>
> I kind of like the 'Zone' name here, to be honest. A heating system in a
> house is broken into zones. A city has neighborhoods zoned for certain
> purposes. So I could use the "Development" Zone, or the "Finance
> Department" Zone.
>
>>> 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.
>
> So I seem to have pulled Zone up a level from what you had in mind. I
> would be fine if we had Zones in Environments. Or Pools in Zones. Either
> way. I do think "Cloud Resource Zone" is a little verbose.
>
>>> 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.
>
> I spent a while thinking about this, before concluding that 'Realm' is
> probably the best possible name. Anything else I come up with is just a
> synonym for 'Realm' and doesn't make anything clearer.
>
>>> Provider -> Cloud Resource Provider
>
> Could we just call this a "Cloud 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.
>
> I think 'Hardware Profile' is one of the few concepts we use that
> intuitively conveys what it does. Deployments vs. Deployables is
> confusing, and it's not at all obvious what an Assembly is. But it
> should be pretty self-evident what a Hardware Profile does. And in that
> case, I say, if it ain't broke, don't fix it.
I'll let you guys discuss the rest of these... :)...
--H
For those who done follow the list.. what are the new names?
Wiki page please.
-- bk