Open Stack

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?

> 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.

Thoughts?
-jay