Open Stack

Excerpts from Fox, Kevin M's message of 2015-12-15 09:07:02 -0800:
> 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.
> 


I agree with your sentiments Kevin. As somebody who struggled with Heat
before it had provider templates, and ended up writing a templating
solution to solve it, I always felt that Heat was holding me back from
writing reusable, composable templates. The CloudFormation way of doing
conditions seems worth copying.

Jinja2 in the engine, however, is not a good idea. Can it be contained?
Maybe. However, you already have Javascript that is built for this exact
purpose and already optimized as such.