----- Original Message ----- > On 23 January 2014 21:39, Jaromir Coufal <jcou...@redhat.com> wrote: > > On 2014/22/01 19:46, Tzu-Mainn Chen wrote: > > > > > So... For now, the attributes are: > > - Name > > - Description > > - Image (Image was discussed on the level of a Role, not Node Profile) > > - Node Profile(s) > > > > Future: > > + Service Specific Configuration (?) > > + Policies (spin up new instance, if...) > > http://docs.openstack.org/developer/heat/template_guide/openstack.html > > Is the list of 'resource types' in heat. You can see that a resource > is [roughly] anything that can be addressed by an API. The instances > we deploy are indeed resources, but not all resources are instances. > > It seems to me that there are two ways to think about the naming problem. > > A) What if we were writing (we're not, but this is a gedanken) a > generic Heat deployment designer. > > B) What if we are not :) > > If we are, not only should we use heat terms, we should probably use > the most generic ones, because we need to expose all of heat. > > However, we aren't. So while I think we *should* use heat terms when > referring to something heat based, we don't need to use the most > generic such term: Instances is fine to describe what we deploy. > Instances on nodes.
The issue I have with Instances is that it gets fairly confusing when working within the UI. From the UI, we have calls to the Heat client grabbing Resources; we also have calls to the Nova client from which we get Instances. When we get information about the Overcloud, we query from Stack -> Resources -> Instance -> Node So calling it Instance<something> would imply (to me) that a Resource has no specificity - which I don't think is the case, as there are attributes to a Heat Resource that mark it as a Compute/Controller/whatever. Calling it Instance<something> and explaining that it *does* apply to a Heat resource (but that we just renamed it) feels simply confusing. Mainn > Separately, what we've got in the template is essentially a tree: > > root: > parameters: > resources: > thing: > type: OS::Service::Thing > ... > thing2: > type: OS::Service::Thing > > And Tuskar's job is to hide the plumbing from that tree (e.g. that we > need an OS::Heat::AccessPolicy there, because there is a single right > answer for our case, and we can programatically generate it. > > The implementation is going to change as we move from merge.py to HOT > etc, but in principle we have one key under resources for each thing > that we scale out. > > I don't know if that helps with the naming of things,but there you go :) > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
