On 2013/12/12 01:21, Robert Collins wrote:
On 12 December 2013 08:15, Tzu-Mainn Chen <tzuma...@redhat.com
* 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?
I think the difference here is if I am looking on Nodes as HW stuff or
if I am interested in services running on it. In the first case, I want
to see 'Management Node', in the second case I want to see 'Management
Instance'. So in the terms of Resources/Nodes it is valid to say
'Management Node'.
* 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?
Same as above - depends on context of what I want to see.
Service Instance is misleading. One service instance is for example
nova-scheduler, not the whole node itself.
I would avoid 'cloud' wording here. Service Node sounds fine for me,
since the context is within Nodes/Resources.
* 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/ ?
Within deployment section, +1 for substitution. However with respect to
my note above (service instance meaning).
* 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'.
-1. Availability is very broad term and might mean various things. I can
have assigned nodes with some role which are available for me - in terms
of reachability for example.
I vote for unallocated, unassigned, free?
* INSTANCE - A role deployed on a node - this is where work actually
happens.
Yes. However this term is overloaded as well. Can we find something better?
* 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?"
* Design the deployment?
(I am sorry for the aversion for 'cloud' - it's just used everywhere :))
* 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.
Role configuration sounds good to me.
My only concern is - if/when we add multiple classes, role configuration
doesn't sound accurate to me. Because Compute is a Role and if I have
multiple Compute classes I feel it is still the same Role for me
(Compute). Or would you expect it to be a different role?
* 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'.
NP with this, I will just avoid using term Flavors in the UI for user
(again overloaded term). Better is HW configuration or Node Profile.
Thanks for drafting this!
-Rob
Thanks guys
-- Jarda
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
