[openstack-dev] [TripleO][Tuskar] Terminology
Robert Collins
robertc at robertcollins.net
Thu Dec 12 00:21:42 UTC 2013
On 12 December 2013 08:15, Tzu-Mainn Chen <tzumainn at redhat.com> 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.
>
> * REGISTRATION - the act of creating a node in Ironic
>
> * 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
Pedantically, this is 'A node with an instance of a management role
running on it'. I think calling it 'management node' is too sticky.
What if we cold migrate it to another machine when a disk fails and we
want to avoid dataloss if another disk were to fail?
Management instance?
> * SERVICE NODE - a node that has been mapped with an overcloud role
Again, the binding to node is too sticky IMNSHO.
Service instance? Cloud instance?
> * 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
s/Node/instance/ ?
> * 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)
I like 'available' because it is a direct statement that doesn't
depend on how things are utilised - mapping or allocation or
deployment or whatever. It is available for us to do something with
it.
'Available nodes'.
> * INSTANCE - A role deployed on a node - this is where work actually happens.
>
> * 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?)
Perhaps 'Size the cloud' ? "How big do you want your cloud to be?"
> * SCHEDULING - the process of deciding which role is deployed on which node
This possible should be a sub step of deployment.
> * SERVICE CLASS - a further categorization within a service role for a particular deployment.
See the other thread where I suggested perhaps bringing the image +
config aspects all the way up - I think that renames 'service class'
to 'Role configuration'. KVM Compute is a role configuration. KVM
compute(GPU) might be another.
> * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to
> a service class
Today the implementation at the plumbing layer can only do 'flavour',
though Heat is open to letting us to 'find an instance from any of X
flavors' in future. Lets not be -too- generic:
'Flavor': The Nova description of a particular machine configuration,
and choosing one is part of setting up the 'role configuration'.
Thanks for drafting this!
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
More information about the OpenStack-dev
mailing list