Open Stack

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



2016年5月12日(木) 17:46 Steven Hardy <shardy at redhat.com>:

> 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/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/cbc30559/attachment.html>