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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
