On further thought, I noticed that "template-based resource" also 
describes an AWS::CloudFormation::Stack; and since those are 
template-based, you could well describe them as "custom" too.

Would you consider "nested stack" to also describe resources of other 
types that are implemented by Python code (e.g., for scaling groups) that 
creates another stack?

I think the name we are trying to settle upon means "nested stack that is 
created by supplying, as the resource type seen after mapping through the 
effective environment, a URL reference to a template".  I really think 
there is no hope of coming up with a reasonable name that includes all of 
that idea.  And in my own work, I have not needed a name that has that 
specific meaning.  I find myself more interested in nested stacks, 
regardless of the surface details of how they are requested.  Yes, the 
surface details have to be handled in some cases (e.g., balancing a 
scaling group across AZs), but that is a relatively small and confined 
matter --- at least in my own work; YMMV.  So my new bottom line is this: 
(1) for the name of the surface syntax details pick any short name that is 
not too confusing/awful, (2) in the documentation closely bind that name 
to a explanation that lays out all the critical parts of the idea, and (3) 
everywhere that you care about nested stacks regardless of the surface 
details of how they are requested in a template, use the term "nested 

OpenStack-dev mailing list

Reply via email to