Open Stack

On 09/09/14 05:52, Steven Hardy wrote:
> Hi Sahdev,
>
> On Tue, Sep 02, 2014 at 11:52:30AM -0400, Sahdev P Zala wrote:
>>     Hello guys,
>>
>>     As you know, the heat-translator project was started early this year with
>>     an aim to create a tool to translate non-Heat templates to HOT. It is a
>>     StackForge project licensed under Apache 2. We have made good progress
>>     with its development and a demo was given at the OpenStack 2014 Atlanta
>>     summit during a half-a-day session that was dedicated to heat-translator
>>     project and related TOSCA discussion. Currently the development and
>>     testing is done with the TOSCA template format but the tool is designed to
>>     be generic enough to work with templates other than TOSCA. There are five
>>     developers actively contributing to the development. In addition, all
>>     current Heat core members are already core members of the heat-translator
>>     project.
>>
>>     Recently, I attended Heat Mid Cycle Meet Up for Juno in Raleigh and
>>     updated the attendees on heat-translator project and ongoing progress. I
>>     also requested everyone for a formal adoption of the project in the
>>     python-heatclient and the consensus was that it is the right thing to do.
>>     Also when the project was started, the initial plan was to make it
>>     available in python-heatclient. Hereby, the heat-translator team would
>>     like to make a request to have the heat-translator project to be adopted
>>     by the python-heatclient/Heat program.
>
> Obviously I wasn't at the meetup, so I may be missing some context here,
> but can you answer some questions please?
>
> - Is the scope for heat-translator only tosca simple-profile, or also the
>    original more heavyweight tosca too?
>
> - If it's only tosca simple-profile, has any thought been given to moving
>    towards implementing support via a template parser plugin, rather than
>    baking the translation into the client?

One idea we discussed at the meetup was to use the template-building 
code that we now have in Heat for building the HOT output from the 
translator - e.g. the translator would produce ResourceDefinition 
objects and add them to a HOTemplate object.

That would actually get us a long way toward an implementation of a 
template format plugin (which basically just has to spit out 
ResourceDefinition objects). So maybe that approach would allow us to 
start in python-heatclient and easily move it later into being a 
full-fledged template format plugin in Heat itself.

> While I see this effort as valuable, integrating the translator into the
> client seems the worst of all worlds to me:
>
> - Any users/services not intefacing to heat via python-heatclient can't use it

Yep, this is a big downside (although presumably we'd want to build in a 
way to just spit out the generated template that can be used by other 
clients).

On the other hand, there is a big downside to having it (only) in Heat 
also - you're dependent on the operator deciding to provide it.

> - You prempt the decision about integration with any higher level services,
>    e.g Mistral, Murano, Solum, if you bake in the translator at the
>    heat level.

Not sure I understand this one.

> The scope question is probably key here - if you think the translator can
> do (or will be able to do) a 100% non-lossy conversion to HOT using only
> Heat, maybe it's time we considered discussing integration into Heat the
> service rather than the client.

I'm open to that discussion too.

> Conversely, if you're going to need other services to fully implement the
> spec, it probably makes sense for the translator to remain layered over
> heat (or integrated with another project which is layered over heat).
>
> Thanks!
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>