[openstack-dev] [magnum] Jinja2 for Heat template

[Yuanying OTSUKA]

Hi, all.

Now, I’m trying to implement following bp.
* https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips

This bp requires to disable/enable “floating ip resource” in heat template
dynamically.
We have 3 options to implement this.

1. Use “conditions function”
*
https://blueprints.launchpad.net/heat/+spec/support-conditions-function
2. Dynamically generate heat template using Jinja2
3. Separate heat template to “kubecluster-with-floatingip.yaml” and
“kubecluster-no-floatingip.yaml”

Option 1 is easy to implement, but unfortunately this isn’t supported by
Mitaka release.
Option 2 needs a Jinja2 template support by Magnum.
Option 3 will bring chaos.

Please let me know what you think.


Thanks
-OTSUKA, Yuanying

[Pavlo Shchelokovskyy]

Hi,

not sure why 3 will bring chaos when implemented properly.

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.

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.

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

Post by Yuanying OTSUKA
Hi, all.
Now, I’m trying to implement following bp.
* https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips
This bp requires to disable/enable “floating ip resource” in heat template
dynamically.
We have 3 options to implement this.
1. Use “conditions function”
*
https://blueprints.launchpad.net/heat/+spec/support-conditions-function
2. Dynamically generate heat template using Jinja2
3. Separate heat template to “kubecluster-with-floatingip.yaml” and
“kubecluster-no-floatingip.yaml”
Option 1 is easy to implement, but unfortunately this isn’t supported by
Mitaka release.
Option 2 needs a Jinja2 template support by Magnum.
Option 3 will bring chaos.
Please let me know what you think.
Thanks
-OTSUKA, Yuanying
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Steven Hardy]

Post by Pavlo Shchelokovskyy
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

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

Post by Pavlo Shchelokovskyy
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.

Post by Pavlo Shchelokovskyy
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/

[Yuanying OTSUKA]

Hi,
Thanks for your helpful comment.

I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc


For example,
* if private network is supplied as parameter, disable creating network
resource.
* if https parameter is enable, tcp 6443 port should be opened instead of
8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP
instead of HTTP

and so on.
So, I want to Jinja2 template to manage it.

I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.


Thanks
- OTSUKA, Yuanying

Post by Steven Hardy

Post by Pavlo Shchelokovskyy
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
http://docs.openstack.org/developer/heat/template_guide/composition.html
http://youtu.be/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

Post by Pavlo Shchelokovskyy
Can you abstract the "thing" (sorry, not quite familiar with Magnum)

that

Post by Pavlo Shchelokovskyy
needs FP + FP itself into a custom resource/nested stack? Then you

could

Post by Pavlo Shchelokovskyy
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
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::None
OS::Magnum::FloatingIP: templates/the_floating_config.yaml
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.

Post by Pavlo Shchelokovskyy
Option 2 is not so bad either IMO (AFAIK Trove was doing that at

sometime,

Post by Pavlo Shchelokovskyy
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/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Hongbin Lu]

We discussed the management of Heat templates several times. It seems the consensus is to leverage the *conditionals*feature from Heat (option #1). From the past discussion, it sounds like option #2 or #3 will significantly complicate our Heat templates, thus incurring burden on maintenance.

However, I agree with Yuanying that option #1 will make Newton (or newer) version of Magnum incompatible with Mitaka (or older) version of OpenStack. A solution I can think of is to have a Jinja2 version of Heat template in the contrib folder, so that operators can swap the Heat templates if they want to run newer version of Magnum with older version of OpenStack. Thoughts.

Best regards,
Hongbin

From: Yuanying OTSUKA [mailto:***@oeilvert.org]
Sent: May-12-16 6:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi,
Thanks for your helpful comment.

I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc


For example,
* if private network is supplied as parameter, disable creating network resource.
* if https parameter is enable, tcp 6443 port should be opened instead of 8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP instead of HTTP

and so on.
So, I want to Jinja2 template to manage it.

I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.


Thanks
- OTSUKA, Yuanying

Post by Pavlo Shchelokovskyy
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

http://youtu.be/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

Post by Pavlo Shchelokovskyy
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.

Post by Pavlo Shchelokovskyy
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/

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-***@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Cammann, Tom]

I’m in broad agreement with Hongbin. Having tried a patch to use jinja2 in the templates, it certainly adds complexity. I am in favor of using conditionals and consuming the latest version of heat. If we intend to support older versions of OpenStack this should be a clearly defined goal and needs to be tested. An aspiration to work with older versions isn’t a good policy.

I would like to understand a bit better the “chaos” option 3 would cause.

Tom

From: Hongbin Lu [mailto:***@huawei.com]
Sent: 12 May 2016 16:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

We discussed the management of Heat templates several times. It seems the consensus is to leverage the *conditionals*feature from Heat (option #1). From the past discussion, it sounds like option #2 or #3 will significantly complicate our Heat templates, thus incurring burden on maintenance.

However, I agree with Yuanying that option #1 will make Newton (or newer) version of Magnum incompatible with Mitaka (or older) version of OpenStack. A solution I can think of is to have a Jinja2 version of Heat template in the contrib folder, so that operators can swap the Heat templates if they want to run newer version of Magnum with older version of OpenStack. Thoughts.

Best regards,
Hongbin

From: Yuanying OTSUKA [mailto:***@oeilvert.org]
Sent: May-12-16 6:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi,
Thanks for your helpful comment.

I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc


For example,
* if private network is supplied as parameter, disable creating network resource.
* if https parameter is enable, tcp 6443 port should be opened instead of 8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP instead of HTTP

and so on.
So, I want to Jinja2 template to manage it.

I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.


Thanks
- OTSUKA, Yuanying

Post by Pavlo Shchelokovskyy
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

http://youtu.be/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

Post by Pavlo Shchelokovskyy
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.

Post by Pavlo Shchelokovskyy
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/

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-***@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Yuanying OTSUKA]

Hi,

My concern is that using option 1 is acceptable or not (because it’s not
implemented yet.)
So, first step, I’ll implement bp:bay-with-no-floating-ips
<https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips> using
option 1,
and option2 or 3 will be implemented later if supporting older versions are
needed. right?

(Sorry, I remember Tom was working for supporing jinja2, but I didn’t know
current status about it.


Thanks
- OTSUKA, Yuanying

Post by Cammann, Tom
I’m in broad agreement with Hongbin. Having tried a patch to use jinja2 in
the templates, it certainly adds complexity. I am in favor of using
conditionals and consuming the latest version of heat. If we intend to
support older versions of OpenStack this should be a clearly defined goal
and needs to be tested. An aspiration to work with older versions isn’t a
good policy.
I would like to understand a bit better the “chaos” option 3 would cause.
Tom
*Sent:* 12 May 2016 16:35
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [magnum] Jinja2 for Heat template
We discussed the management of Heat templates several times. It seems the
consensus is to leverage the *conditionals*feature from Heat (option #1).
From the past discussion, it sounds like option #2 or #3 will significantly
complicate our Heat templates, thus incurring burden on maintenance.
However, I agree with Yuanying that option #1 will make Newton (or newer)
version of Magnum incompatible with Mitaka (or older) version of OpenStack.
A solution I can think of is to have a Jinja2 version of Heat template in
the contrib folder, so that operators can swap the Heat templates if they
want to run newer version of Magnum with older version of OpenStack.
Thoughts.
Best regards,
Hongbin
*Sent:* May-12-16 6:02 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [magnum] Jinja2 for Heat template
Hi,
Thanks for your helpful comment.
I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc

For example,
* if private network is supplied as parameter, disable creating network resource.
* if https parameter is enable, tcp 6443 port should be opened instead of
8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP instead of HTTP
and so on.
So, I want to Jinja2 template to manage it.
I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.
Thanks
- OTSUKA, Yuanying

Post by Pavlo Shchelokovskyy
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
http://docs.openstack.org/developer/heat/template_guide/composition.html
http://youtu.be/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

Post by Pavlo Shchelokovskyy
Can you abstract the "thing" (sorry, not quite familiar with Magnum)

that

Post by Pavlo Shchelokovskyy
needs FP + FP itself into a custom resource/nested stack? Then you

could

Post by Pavlo Shchelokovskyy
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
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::None
OS::Magnum::FloatingIP: templates/the_floating_config.yaml
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.

Post by Pavlo Shchelokovskyy
Option 2 is not so bad either IMO (AFAIK Trove was doing that at

sometime,

Post by Pavlo Shchelokovskyy
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/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Hongbin Lu]

Sounds good to me.

Best regards,
Hongbin

From: Yuanying OTSUKA [mailto:***@oeilvert.org]
Sent: May-12-16 9:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi,

My concern is that using option 1 is acceptable or not (because it’s not implemented yet.)
So, first step, I’ll implement bp:bay-with-no-floating-ips<https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips> using option 1,
and option2 or 3 will be implemented later if supporting older versions are needed. right?

(Sorry, I remember Tom was working for supporing jinja2, but I didn’t know current status about it.


Thanks
- OTSUKA, Yuanying


2016幎5月13日(金) 3:34 Cammann, Tom <***@hpe.com<mailto:***@hpe.com>>:
I’m in broad agreement with Hongbin. Having tried a patch to use jinja2 in the templates, it certainly adds complexity. I am in favor of using conditionals and consuming the latest version of heat. If we intend to support older versions of OpenStack this should be a clearly defined goal and needs to be tested. An aspiration to work with older versions isn’t a good policy.

I would like to understand a bit better the “chaos” option 3 would cause.

Tom

From: Hongbin Lu [mailto:***@huawei.com<mailto:***@huawei.com>]
Sent: 12 May 2016 16:35

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

We discussed the management of Heat templates several times. It seems the consensus is to leverage the *conditionals*feature from Heat (option #1). From the past discussion, it sounds like option #2 or #3 will significantly complicate our Heat templates, thus incurring burden on maintenance.

However, I agree with Yuanying that option #1 will make Newton (or newer) version of Magnum incompatible with Mitaka (or older) version of OpenStack. A solution I can think of is to have a Jinja2 version of Heat template in the contrib folder, so that operators can swap the Heat templates if they want to run newer version of Magnum with older version of OpenStack. Thoughts.

Best regards,
Hongbin

From: Yuanying OTSUKA [mailto:***@oeilvert.org]
Sent: May-12-16 6:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi,
Thanks for your helpful comment.

I didn’t know about the pattern you suggested.
We often want to “if” or “for” etc


For example,
* if private network is supplied as parameter, disable creating network resource.
* if https parameter is enable, tcp 6443 port should be opened instead of 8080 at“OS::Neutron::SecurityGroup".
* if https parameter is enable, loadbalancing protocol should be TCP instead of HTTP

and so on.
So, I want to Jinja2 template to manage it.

I’ll try to use the composition model above,
and also test the limited use of jinja2 templating.


Thanks
- OTSUKA, Yuanying

Post by Pavlo Shchelokovskyy
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

http://youtu.be/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

Post by Pavlo Shchelokovskyy
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.

Post by Pavlo Shchelokovskyy
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/

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-***@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-***@lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-***@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev