On 12/11/2013 08:54 PM, Jay Dobies wrote:
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?
See wireframes [1] page 19, says "Compute Nodes" which is the default
service class. Box below "Create New Compute Class" serves to creation
of new service class. Nodes in Service Classes are differentiated by
Node Profiles.
[1]
http://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf
<http://people.redhat.com/%7Ejcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf>
* 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jirka
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
