Open Stack

On 2013/12/12 01:21, Robert Collins wrote:
> On 12 December 2013 08:15, Tzu-Mainn Chen <tzumainn at 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