Thanks for the suggestions, I'll give that patch another crack. -Angus
On Sat, Sep 20, 2014 at 10:11 AM, Qiming Teng <teng...@linux.vnet.ibm.com> wrote: > On Fri, Sep 19, 2014 at 11:20:43AM +0200, Thomas Spatzier wrote: > > > From: Mike Spreitzer <mspre...@us.ibm.com> > > > To: "OpenStack Development Mailing List \(not for usage questions\)" > > > <openstack-dev@lists.openstack.org> > > > Date: 19/09/2014 07:15 > > > Subject: Re: [openstack-dev] [Heat] naming of provider template for > docs > > > > > > Angus Salkeld <asalk...@mirantis.com> wrote on 09/18/2014 09:33:56 PM: > > > > > > > Hi > > > > > > > I am trying to add some docs to openstack-manuals hot_guide about > > > > using provider templates : https://review.openstack.org/#/c/121741/ > > > > > > > Mike has suggested we use a different term, he thinks "provider" is > > > > confusing. > > > > I agree that at the minimum, it is not very descriptive. > > > > > > > Mike has suggested "nested stack", I personally think this means > > > something a > > > > bit more general to many of us (it includes the concept of aws > > > stacks) and may > > > > I suggest "template resource" - note this is even the class name for > > > > this exact functionality. > > > > > > > > Thoughts? > > > > > > > Option 1) stay as is "provider templates" > > > > Option 2) "nested stack" > > > > Option 3) "template resource" > > > > Out of those 3 I like #3 the most, even though not perfect as Mike > > discussed below. > > > > > > > Thanks for rising to the documentation challenge and trying to get > > > good terminology. > > > > > > I think your intent is to describe a category of resources, so your > > > option 3 is superior to option 1 --- the thing being described is > > > not a template, it is a resource (made from a template). > > > > > > I think > > > > > > Option 4) "custom resource" > > > > That one sound too generic to me, since also custom python based resource > > plugins are custom resources. > > +1. > > 'Custom resource' may cause more confusion. > > > > > > > would be even better. My problem with "template resource" is that, > > > to someone who does not already know what it means, this looks like > > > it might be a kind of resource that is a template (e.g., for > > > consumption by some other resource that does something with a > > > template), rather than itself being something made from a template. > > > If you want to follow this direction to something perfectly clear, > > > you might try "templated resource" (which is a little better) or > > > "template-based resource" (which I think is pretty clear but a bit > > > wordy) --- but an AWS::CloudFormation::Stack is also based on a > > > template. I think that if you try for a name that really says all > > > of the critical parts of the idea, you will get something that is > > > too wordy and/or awkward. It is true that "custom resource" begs > > > the question of how the user accomplishes her customization, but at > > > least now we have the reader asking the right question instead of > > > being misled. > > > > I think "template-based resource" really captures the concept best. And > it > > is not too wordy IMO. > > If it helps to explain the concept intuitively, I would be in favor of > it. > > Agreed. If it sounds too wordy, just use 'template resource' would be > okay. > > > Regards, > > Thomas > > > > > > _______________________________________________ > 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
