> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
