Open Stack

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.cammann at 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.lu at 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:yuanying at oeilvert.org
> <yuanying at 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 <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
>
> __________________________________________________________________________
> 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/20160513/032d2962/attachment.html>