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 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
