Open Stack

On Thu, May 12, 2016 at 11:08:02AM +0300, Pavlo Shchelokovskyy wrote:
>    Hi,
> 
>    not sure why 3 will bring chaos when implemented properly.

I agree - heat is designed with composition in mind, and e.g in TripleO
we're making heavy use of it for optional configurations and it works
pretty well:

http://docs.openstack.org/developer/heat/template_guide/composition.html

https://www.youtube.com/watch?v=fw0JhywwA1E

http://hardysteven.blogspot.co.uk/2015/05/tripleo-heat-templates-part-1-roles-and.html

https://github.com/openstack/tripleo-heat-templates/tree/master/environments

>    Can you abstract the "thing" (sorry, not quite familiar with Magnum) that
>    needs FP + FP itself into a custom resource/nested stack? Then you could
>    use single master template plus two environments (one with FP, one
>    without), and choose which one to use right where you have this logic
>    split in your code.

Yes, this is exactly the model we make heavy use of in TripleO, it works
pretty well.

Note there's now an OS::Heat::None resource in heat, which makes it easy to
conditionally disable things (without the need for a noop.yaml template
that contains matching parameters):

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::None

So you'd have two environment files like:

cat enable_floating.yaml:
resource_registry:
  OS::Magnum::FloatingIP: templates/the_floating_config.yaml

cat disable_floating.yaml:
resource_registry:
  OS::Magnum::FloatingIP: OS::Heat::None

Again, this pattern is well proven and works pretty well.

Conditionals may provide an alternative way to do this, but at the expense
of some additional complexity inside the templates.

>    Option 2 is not so bad either IMO (AFAIK Trove was doing that at sometime,
>    not sure of current status), but the above would be nicer.

Yes, in the past[1] I've commented that the composition model above may be
preferable to jinja templating, but recently I've realized there are pros
and cons to each approach.

The heat composition model works pretty well when you want to combine
multiple pieces (nested stacks) which contain some mixture of different
resources, but it doesn't work so well when you want to iterate over a
common pattern and build a template (e.g based on a loop).

You can use ResourceGroups in some cases, but that adds to the stack depth
(number of nested stacks), and may not be workable for upgrades, so TripleO
is now looking at some limited use of jinja2 templating also, I agree it's
not so bad provided the interfaces presented to the user are carefully
constrained.

Steve

[1] https://review.openstack.org/#/c/211771/