Open Stack

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) [rpothier at cisco.com]
> *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 <skraynev at mirantis.com <mailto:skraynev at mirantis.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Wednesday, December 9, 2015 at 5:42 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.