Open Stack

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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jirka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/ac446938/attachment.html>