Open Stack

So glad we're hashing this out now. This will save a bunch of headaches 
in the future. Good call pushing this forward.

On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote:
> Hi,
>
> I'm trying to clarify the terminology being used for Tuskar, which may be helpful so that we're sure
> that we're all talking about the same thing :)  I'm copying responses from the requirements thread
> and combining them with current requirements to try and create a unified view.  Hopefully, we can come
> to a reasonably rapid consensus on any desired changes; once that's done, the requirements can be
> updated.
>
> * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly
>         useful for a given role.

Do we ever need to distinguish between undercloud and overcloud nodes?

>       * REGISTRATION - the act of creating a node in Ironic

DISCOVERY - The act of having nodes found auto-magically and added to 
Ironic with minimal user intervention.

>
>       * ROLE - a specific workload we want to map onto one or more nodes. Examples include 'undercloud control plane', 'overcloud control
>         plane', 'overcloud storage', 'overcloud compute' etc.
>
>           * MANAGEMENT NODE - a node that has been mapped with an undercloud role
>           * SERVICE NODE - a node that has been mapped with an overcloud role
>              * COMPUTE NODE - a service node that has been mapped to an overcloud compute role
>              * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role
>              * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role
>              * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role
>
>           * UNDEPLOYED NODE - a node that has not been mapped with a role
>                * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?)
>                                     - (after reading lifeless's explanation, I agree that "allocation" may be a
>                                        misleading term under TripleO, so I personally vote for UNDEPLOYED)

Undeployed still sounds a bit odd to me when paired with the word role. 
I could see deploying a workload "bundle" or something, but a role 
doesn't feel like a tangible thing that is pushed out somewhere.

Unassigned? As in, it hasn't been assigned a role yet.

>       * INSTANCE - A role deployed on a node - this is where work actually happens.

I'm fine with "instance", but the the phrasing "a role deployed on a 
node" feels odd to me in the same way "undeployed" does. Maybe a slight 
change to "A node that has been assigned a role", but that also may be 
me being entirely too nit-picky.

To put it in context, on a scale of 1-10, my objection to this and 
"undeployed" is around a 2, so don't let me come off as strenuously 
objecting.

> * DEPLOYMENT
>
>       * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role
>             * another option - DISTRIBUTE NODES (?)
>                                   - (I think the former is more accurate, but perhaps there's a better way to say it?)
>
>       * SCHEDULING - the process of deciding which role is deployed on which node

I know this derives from a Nova term, but to me, the idea of 
"scheduling" carries a time-in-the-future connotation to it. The 
interesting part of what goes on here is the assignment of which roles 
go to which instances.

>       * SERVICE CLASS - a further categorization within a service role for a particular deployment.

I don't understand this one, can you add a few examples?

>            * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to
>                             a service class

Even without knowing what "service class" is, I like this one.  :)

>
>
> Does this seem accurate?  All feedback is appreciated!
>
> Mainn

Thanks again  :D

  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>