On 12/15/2015 12:07 PM, Fox, Kevin M wrote:
My $0.02:
heat as it is today, requires all users to be devops, and to carefully
craft the templates launched specific to the cloud and the particular
app they are trying to write. Making sharing code between heat users
difficult. This means the potential user base of heat is restricted to
developers knowledgeable in heat template format, or those using
openstack services that wrap up in front of heat (trove, sahara, etc).
This mostly relegates heat to the role of "plumbing". Where as, I see it
as a first class orchestration engine for the cloud. Something that
should be usable by all in its own right.
Just about every attempt I've seen so far has required something like
jinja in front to generate the heat templates since heat itself is not
generic enough. This means its not available from Horizon, and then is
only usable by a small fraction of openstack users.
I've had some luck with aproximating conditionals using maps and nested
stacks. It works but its really ugly to code. But from an end users
perspective, its very nice to use.
Since everyone's reinventing the templating wheel over and over, heat
should itself gain a bit more templatability in its templates so that
everyone can stop having to rewrite template engines on top of heat, and
heat users don't have to take so much time customizing templates so they
can launch them.
I am incredibly late to this thread, so sorry for that. Jinja2 does have
sandboxing support according to their docs, so it wouldn't be turing
complete (which is good) and Jinja conditionals are already documented
(thanks, Jinja community!).
I don't particularly care what the best solution to making conditionals
available is. if you can guarantee jinja templates will always halt in a
reasonable amount of time and is sandboxed appropriately, then sticking
it in heat would be a good solution. If not, even some simple
conditionals ala AWS would be extremely welcome. But either way, it
should take heat parameters in, and operate on them. The heat parameters
section is a great contract today between heat users, and heat template
developers. Its one of the coolest things about Heat. It makes for a
much better user experience in Horizon and the cli. And when I say
users, I mean "heat users" != "heat template developers". In the same
way, a bash script user may not be able to even read a bash script, but
they don't have to edit one to use it. They just call it with parameters.
Thanks,
Kevin
------------------------------------------------------------------------
*From:* Rob Pothier (rpothier) [[email protected]]
*Sent:* Tuesday, December 15, 2015 7:50 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Heat] Status of the Support Conditionals
in Heat templates
Hi Sergey,
I agree with your feeling, this is from the Heat Wiki page.
"Heat also endeavours to provide compatibility with the AWS
CloudFormation template format, so that many existing CloudFormation
templates can be launched on OpenStack."
Note also, there was another review that attempted implement this, but
stalled.
https://review.openstack.org/#/c/84468/
Rob
From: Sergey Kraynev <[email protected] <mailto:[email protected]>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]
<mailto:[email protected]>>
Date: Wednesday, December 9, 2015 at 5:42 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]
<mailto:[email protected]>>
Subject: [openstack-dev] [Heat] Status of the Support Conditionals in
Heat templates
Hi Heaters,
On the last IRC meeting we had a question about Support Conditionals
spec [1].
Previous attempt for this staff is here [2].
The example of first POC in Heat can be reviewed here [3]
As I understand we have not had any complete decision about this work.
So I'd like to clarify feelings of community about it. This
clarification may be done as answers for two simple questions:
- Why do we want to implement it?
- Why do NOT we want to implement it?
My personal feeling is:
- Why do we want to implement it?
* A lot of users wants to have similar staff.
* It's already presented in AWS, so will be good to have this
feature in Heat too.
- Why do NOT we want to implement it?
* it can be solved with Jinja [4] . However I don't think, that
it's really important reason for blocking this work.
Please share your idea about two questions above.
It should allows us to eventually decide, want we implement it or not.
[1] https://review.openstack.org/#/c/245042/
[2] https://review.openstack.org/#/c/153771/
[3] https://review.openstack.org/#/c/221648/1
[4] http://jinja.pocoo.org/
--
Regards,
Sergey.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
