On 12 December 2013 08:15, Tzu-Mainn Chen <tzuma...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
