singleton template

[Kevin Fox]

Some stacks benefit from sharing resources. Like security groups.

The user can manually launch the shared stack, then pass the output to each individual stack at launch time.

Alternately, the user can make the individual stack a nested stack of the shared stack, and update it to include more individual stacks as needed, but editing json is much more technically difficult then hitting a few buttons and filling out a few text boxes in dashboard to start a new individual stack.

To be more user friendly, it would be nice to just launch the individual stack and have it create the shared singleton stack if it doesn't already exist, and share the existing singleton if it does. Even nicer would be for it to reference count the singleton and delete it only when the last stack deletes.

In the individual template, it would list the singleton template just like a nested stack, and give is a singleton name. The name would be unique per tenant. You could then use Fn::GetAtt on the singleton to get references and use them in your stack as normal.

[Steve Baker (steve-stevebaker)]

This is a feature, could you please raise it as a blueprint?

[Clint Byrum (clint-fewbar)]

We have Wishlist importance for feature requests too.

I feel like blueprints are things with a plan, where as bugs with problem statements can be left open with Wishlist status until somebody properly designs a solution.

[Angus Salkeld (asalkeld)]

This is a very cool idea, our current loadbalancer and dbinstance provider templates could use this (per tenant) and
I could imagine many other similar types of provider templates could too. Although I wonder if you would call this
 an "on demand service" then?

[Angus Salkeld (asalkeld)]

This is partly implemented as: https://review.openstack.org/134848 (external_references).