[openstack-dev] [TripleO][Tuskar] Terminology

Tzu-Mainn Chen tzumainn at redhat.com
Sat Dec 14 04:30:07 UTC 2013


> Thanks Mainn, comments inline :)
> 
> On Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote:
> > Thanks for the reply!  Let me try and address one particular section for
> > now,
> > since it seems to be the part causing the most confusion:
> > 
> > > >      * SERVICE CLASS - a further categorization within a service role
> > > >      for a
> > > >      particular deployment.
> > > > 
> > > >           * NODE PROFILE - a set of requirements that specify what
> > > >           attributes a node must have in order to be mapped to
> > > >                            a service class
> > > 
> > > I think I still need some more information about the above two. They
> > > sound vaguely like Cobbler's system profiles... :)
> > 
> > I admit that this concept was a bit fuzzy for me as well, but after a few
> > IRC
> > chats, I think I have a better handle on this.  Let me begin with my
> > understanding of what
> > happens in Heat, using Heat terminology:
> > 
> > A Heat stack template defines RESOURCES.  When a STACK is deployed using
> > that template,
> > the resource information in the template is used to instantiate an INSTANCE
> > of that
> > resource on a NODE.  Heat can pass a FLAVOR (flavors?) to nova-scheduler in
> > order to
> > filter for appropriate nodes.
> > 
> > So: based on that explanation, here's what Tuskar has been calling the
> > above:
> > 
> > HEAT TERM == TUSKAR TERM
> > ------------------------
> > NODE == NODE
> > STACK == DEPLOYMENT
> > INSTANCE == INSTANCE
> > RESOURCE == SERVICE CLASS (at the very least, it's a one-to-one
> > correspondence)
> > FLAVOR == NODE PROFILE
> > ???    == ROLE
> > 
> > The ??? is because ROLE is entirely a Tuskar concept, based on what TripleO
> > views
> > as the fundamental kinds of building blocks for an overcloud: Compute,
> > Controller,
> > Object Storage, Block Storage.  A ROLE essentially categorizes
> > RESOURCES/SERVICE CLASSES;
> > for example, the Control ROLE might contain a control-db resource,
> > control-secure resource,
> > control-api resource, etc.
> 
> So, based on your explanation above, perhaps it makes sense to just
> ditch the concept of roles entirely? Is the concept useful more than
> just being a list of workloads that a node is running?

I think it's still useful from a UI perspective, especially for large deployments
with lots of running instances.  Quickly separating out control/compute/storage
instances seems like a good feature.

> > Heat cares only about the RESOURCE and not the ROLE; if the roles were
> > named Foo1, Foo2, Foo3,
> > and Barney, Heat would not care.  Also, if the UI miscategorized, say, the
> > control-db resource
> > under the Block Storage category - Heat would again not care, and the
> > deploy action would work.
> > 
> > From that perspective, I think the above terminology should either *be* the
> > Heat term, or be
> > a word that closely corresponds to the intended purpose.  For example, I
> > think DEPLOYMENT reasonably
> > describes a STACK, but I don't think SERVICE CLASS works for RESOURCE.  I
> > also think ROLE should be
> > RESOURCE CATEGORY, since that seems to me to be the most straightforward
> > description of its purpose.
> 
> I agree with you that either the Tuskar terminology should match the
> Heat terminology, or there should be a good reason for it not to match
> the Heat terminology.
> 
> With regards to "stack" vs. "deployment", perhaps it's best to just
> stick with "stack".
> 
> For "service class", "node profile", and "role", perhaps it may be
> useful to scrap those terms entirely and use a term that the Solum
> project has adopted for describing an application deployment: the
> "plan".
> 
> In Solum-land, the "plan" is simply the instructions for deploying the
> application. In Tuskar-land, the "plan" would simply be the instructions
> for setting up the undercloud.
> 
> So, instead of "SIZE THE ROLES", you would just be defining the "plan"
> in Tuskar.

I'm not against the use of the word "plan" - it's accurate and generic,
which are both pluses. But even if we use that term, we still need to name
the internals of the plan, which would then have several components -
"sizing the roles" is just one step the user needs to perform.  And we still
need terms for the objects within the plan - the resources/service classes and
flavors/node profiles - because the UI and API still need to manipulate them.

Mainn


> Thoughts?
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list