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
Given that we'll need to update the code to reflect the new names, along with the related documentation etc., there's a great deal to be said for actually settling on a set of names.
So, here's the list:
Image template -> Component Outline Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application Pool Family/Environment -> Cloud Pool -> Cloud Resource Zone User Defined Realm -> Cloud Resource Cluster Provider -> Cloud Resource Provider Hardware Profile -> Cloud Resource Profile
Angus
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?
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 Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application
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."
But I fear we're overloading an already-overloaded term. To me, "EC2" is a cloud, and so a local RHEV installation, and so is Rackspace. If someone says they're creating a new Cloud, it could now mean a number of things.
In keeping with the below four names, could we just call this a "Cloud Resource" instead? Does that make sense? EC2 is the Cloud, "Finance Department" is the Cloud Resource, and "Accounts Receivable Tools" is the Cloud Resource Zone.
Best, Matt
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
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.
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.
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
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
On Fri, Nov 11, 2011 at 04:52:22PM -0500, Bryan Kearney wrote:
For those who done follow the list.. what are the new names?
Wiki page please.
Judging from this thread, they're not exactly settled.
You can find the original post here, though: https://fedorahosted.org/pipermail/aeolus-devel/2011-November/006610.html
From: Bryan Kearney bkearney@redhat.com Date: Fri, 11 Nov 2011 16:52:22 -0500
For those who done follow the list.. what are the new names?
Wiki page please.
Hear hear.
FWIW, I liked the idea of "template" because it connotes "here's a thing which you can use to stamp out a bunch of similar things which you can then turn around and use elsewhere. I think trying to call a deployable and application is going to be massively confusing, that word has too much baggage. I liked "deployable" because it *doesn't* have baggage, and is a thing which you can deploy. If you want something less techie sounding, I'd advocate a cluster or a group. At one point, we suggested "clump". I kind of liked that one.
On 11/11/11 17:48 +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
Given that we'll need to update the code to reflect the new names, along with the related documentation etc., there's a great deal to be said for actually settling on a set of names.
So, here's the list:
Image template -> Component Outline Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application Pool Family/Environment -> Cloud Pool -> Cloud Resource Zone User Defined Realm -> Cloud Resource Cluster Provider -> Cloud Resource Provider Hardware Profile -> Cloud Resource Profile
Ugh, where is clalance when we need him? Seriously, how many times do we need to rename these things? While not all are neccessarily bad (though Deployment => Application is definitely horrible), I am just tired of the churn here on naming. How can we expect users to know what we are talking about if we constantly are changing our glossary?
-j
Angus
On 11/11/2011 08:49 PM, Jason Guiditta wrote:
On 11/11/11 17:48 +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
Given that we'll need to update the code to reflect the new names, along with the related documentation etc., there's a great deal to be said for actually settling on a set of names.
So, here's the list:
Image template -> Component Outline Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application Pool Family/Environment -> Cloud Pool -> Cloud Resource Zone User Defined Realm -> Cloud Resource Cluster Provider -> Cloud Resource Provider Hardware Profile -> Cloud Resource Profile
Ugh, where is clalance when we need him? Seriously, how many times do we need to rename these things? While not all are neccessarily bad (though Deployment => Application is definitely horrible), I am just tired of the churn here on naming. How can we expect users to know what we are talking about if we constantly are changing our glossary?
While I sympathise with the sentiment, I see this as the final discussion on the naming matter. After this, the names will be settled and for better or worse, we'll be stuck with them.
Remember that what's now Aeolus Conductor went through about four different names. Then we picked one, bought the domain and now it's done.
With the 1.0 getting closer every day, this is probably the only time we can actually finalize this.
-j
Angus
Ugh, where is clalance when we need him? Seriously, how many times do we need to rename these things? While not all are neccessarily bad (though Deployment => Application is definitely horrible), I am just tired of the churn here on naming. How can we expect users to know what we are talking about if we constantly are changing our glossary?
While I sympathise with the sentiment, I see this as the final discussion on the naming matter. After this, the names will be settled and for better or worse, we'll be stuck with them.
Remember that what's now Aeolus Conductor went through about four different names. Then we picked one, bought the domain and now it's done.
With the 1.0 getting closer every day, this is probably the only time we can actually finalize this.
I agree with Jay and clalance on this one.
1.0 or post-1.0 doesn't matter. Products change names all the time. Domains are dirt cheap.
We only have one shot w/ Aeolus, lets use that to develop a solid product. Not continuously spin our wheels w/ branding / marketing.
-Mo
On 11/11/2011 06:48 PM, 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
Given that we'll need to update the code to reflect the new names, along with the related documentation etc., there's a great deal to be said for actually settling on a set of names.
So, here's the list:
Image template -> Component Outline Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application Pool Family/Environment -> Cloud Pool -> Cloud Resource Zone User Defined Realm -> Cloud Resource Cluster Provider -> Cloud Resource Provider Hardware Profile -> Cloud Resource Profile
Angus
Hi, my 2 cents: much more confusing than current naming. Most confusing are: Application - as a user I would expect real application (=program) under this naming Cloud - I would expect cloud provider Cloud Resource Zone - sounds like a provider realm to me Component Outline - 'component' is very abstract (confusing), I wouldn't have an idea what to imagine under this name. 'Template' is clear.
Jan
On Tue, Nov 15, 2011 at 02:00:50PM +0100, Jan Provaznik wrote:
Hi, my 2 cents: much more confusing than current naming.
I agree 100% here. I think the goal of clear, consistent naming is important, but I think many on the list so far are worse than what we have now, and that we're renaming some terms that don't need changing. The goal should be to change the names which are unclear or misleading, but to leave those that don't need changing.
As others have requested, and to try to move this discussion forward to constructive brainstorming, I have put together a wiki page: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Renaming_All_the_...
I tried to do two things for each term:
- Give a one-sentence description of what the term actually means. I think this is critically important and many of my descriptions are bad or incomplete. Note that I struggled to clearly explain Assemblies or Environments; please help! I think getting back to the definition and agreeing on what the things *are* will help us name them clearly.
- List proposed names. I think of this as a brainstorming exercise, so please add your own suggestions. Where I added my own suggestions, I tried to write a few words in parenthesis about why I chose the name.
I used sub-bullet-points to comment on existing names, though really I think the focus should be on contributing suggestions, not shooting down existing ones.
Is this a more helpful, more-constructive format?
-- Matt
On 16/11/2011, at 3:29 AM, Matt Wagner wrote:
On Tue, Nov 15, 2011 at 02:00:50PM +0100, Jan Provaznik wrote:
Hi, my 2 cents: much more confusing than current naming.
<snip>
As others have requested, and to try to move this discussion forward to constructive brainstorming, I have put together a wiki page: https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Renaming_All_the_...
<snip>
Is this a more helpful, more-constructive format?
Yep. From my point of view, this page should also have a picture to show the relationships between the items. Help illustrate things, etc.
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
On 11/11/2011 12:48 PM, 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
Given that we'll need to update the code to reflect the new names, along with the related documentation etc., there's a great deal to be said for actually settling on a set of names.
So, here's the list:
Image template -> Component Outline Assembly -> Component Blueprint Deployable -> Application Blueprint Deployment -> Application Pool Family/Environment -> Cloud Pool -> Cloud Resource Zone User Defined Realm -> Cloud Resource Cluster Provider -> Cloud Resource Provider Hardware Profile -> Cloud Resource Profile
Angus
Is this thread dead?
I'm trying to figure out if the changes to any of names were ever settled. Looking at the wiki page (https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Renaming_All_the_...), it looks like MattW is the only one to have commented on any of the names, or provided alternate suggestions for the names.
Ultimately, I don't really have any input to add to the discussion. I'm just in the middle of spiffing up some documentation and wanted to be as current as possible in my lexicon.
On Wed, Dec 07, 2011 at 12:05:55PM -0500, Greg Blomquist wrote:
Is this thread dead?
I'm trying to figure out if the changes to any of names were ever settled. Looking at the wiki page (https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Renaming_All_the_...), it looks like MattW is the only one to have commented on any of the names, or provided alternate suggestions for the names.
Ultimately, I don't really have any input to add to the discussion. I'm just in the middle of spiffing up some documentation and wanted to be as current as possible in my lexicon.
The names were not accepted upstream. It looks like the product team wants to use the new names in what's shipped, however, so in the short term both sets of names are likely to be in circulation -- one for the upstream version, and one for the shipping product.
Hopefully we'll get them reconciled, though right at the moment we're largely preoccupied with bugfixing, so it's not a top priority.
-- Matt
On 12/07/2011 02:39 PM, Matt Wagner wrote:
On Wed, Dec 07, 2011 at 12:05:55PM -0500, Greg Blomquist wrote:
Is this thread dead?
I'm trying to figure out if the changes to any of names were ever settled. Looking at the wiki page (https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Renaming_All_the_...), it looks like MattW is the only one to have commented on any of the names, or provided alternate suggestions for the names.
Ultimately, I don't really have any input to add to the discussion. I'm just in the middle of spiffing up some documentation and wanted to be as current as possible in my lexicon.
The names were not accepted upstream. It looks like the product team wants to use the new names in what's shipped, however, so in the short term both sets of names are likely to be in circulation -- one for the upstream version, and one for the shipping product.
Hopefully we'll get them reconciled, though right at the moment we're largely preoccupied with bugfixing, so it's not a top priority.
Understood. I'll stick with the "classic" names for now.
Thanks Matt!
--- Greg
-- Matt
aeolus-devel@lists.fedorahosted.org