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 <sha...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
