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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
