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 <tom.camm...@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:hongbin...@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:yuany...@oeilvert.org > <yuany...@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 > > > > > > > > 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 >
__________________________________________________________________________ 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
