Open Stack

Hi all,

we had some discussions the last couple of days among a few people on how
we could go on and make progress on the HOT DSL topic. I would like to give
a gist of those discussions form my perspective - others please chime in -
so everyone is up to date and can share opinions.

We had quite some discussions on concepts for a couple of weeks, and some
people have drafted HOT templates to review and comment on. What seems
necessary now is to get some running code to gain experience with HOT and
develop it incrementally, i.e. start very basic, then add feature by
feature over time. This work seems best to be done in both the heat engine
(more comments below) and the heat-templates repo, to connect thoughts to
reality.
There are also enabling items being worked on in the heat engine (e.g. the
whole "providers" topic, and a couple of other BPs), but those should not
hold of the DSL work. I think it makes sense to prototype HOT in parallel.
This can also serve as good validation of the concepts being implemented in
the engine, and we can meet in the middle. I.e. we would do a combined
top-down and bottom-up approach.

I have just created a new BP for this HOT hello world work that I would
suggest for the H-2 timeframe:

https://blueprints.launchpad.net/heat/+spec/hot-hello-world

This is very basic work, and depending on progress we can add more BPs
on-top. But it is a small actionable starting point for now. Steven Hardy
posted an initial draft patch for the template parser code in the engine
that can serve as starting point. The plan is basically to do this work
without impacting current CFN processing. We would have to some extend two
code paths for the time being, where one is the default and one is for HOT.
At some point in the future when HOT is mature enough and can step up with
CFN we could move the CFN layer into an envisioned pluggable parser layer
for "other formats" than HOT.
Realistically, it might be that HOT does become production ready in the
Havana timeframe, but this approach would allow for having it there, so
people can play with it and give feedback.

A general way for going forward that I can imagine is like this: for each
feature/concept we add to HOT, work on the parser code (engine) and a
corresponding sample would always go hand in hand. So a deliverable would
always consist of an enhanced sample with feature X plus the parser code to
process feature X. And in addition, we should always also update
documentation of HOT to document feature X.
One example would be additionl of relations to HOT, or expression of the
provider concept.

Regards,
Thomas