<font size=2 face="sans-serif">Thanks all for a good discussion.  </font>
<br>
<br><font size=2 face="sans-serif">I would like to call for an agreement
on this subject in Wednesday's (Oct 8th) Heat IRC meeting. It has been
added in the agenda.</font>
<br>
<br><font size=2 face="sans-serif">Thanks!<br>
</font>
<br><font size=2 face="sans-serif"><br>
Regards, <br>
Sahdev Zala </font><font size=1 face="sans-serif"><br>
IBM SWG Standards Strategy <br>
Durham, NC <br>
(919)486-2915 T/L: 526-2915 </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Steven Hardy <shardy@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">09/23/2014 05:46 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[Heat] Request for python-heatclient project to adopt heat-translator</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Fri, Sep 19, 2014 at 06:54:27PM -0400, Zane Bitter
wrote:<br>
> On 09/09/14 05:52, Steven Hardy wrote:<br>
> >Hi Sahdev,<br>
> ><br>
> >On Tue, Sep 02, 2014 at 11:52:30AM -0400, Sahdev P Zala wrote:<br>
> >>    Hello guys,<br>
> >><br>
> >>    As you know, the heat-translator project was
started early this year with<br>
> >>    an aim to create a tool to translate non-Heat
templates to HOT. It is a<br>
> >>    StackForge project licensed under Apache 2.
We have made good progress<br>
> >>    with its development and a demo was given at
the OpenStack 2014 Atlanta<br>
> >>    summit during a half-a-day session that was
dedicated to heat-translator<br>
> >>    project and related TOSCA discussion. Currently
the development and<br>
> >>    testing is done with the TOSCA template format
but the tool is designed to<br>
> >>    be generic enough to work with templates other
than TOSCA. There are five<br>
> >>    developers actively contributing to the development.
In addition, all<br>
> >>    current Heat core members are already core members
of the heat-translator<br>
> >>    project.<br>
> >><br>
> >>    Recently, I attended Heat Mid Cycle Meet Up
for Juno in Raleigh and<br>
> >>    updated the attendees on heat-translator project
and ongoing progress. I<br>
> >>    also requested everyone for a formal adoption
of the project in the<br>
> >>    python-heatclient and the consensus was that
it is the right thing to do.<br>
> >>    Also when the project was started, the initial
plan was to make it<br>
> >>    available in python-heatclient. Hereby, the
heat-translator team would<br>
> >>    like to make a request to have the heat-translator
project to be adopted<br>
> >>    by the python-heatclient/Heat program.<br>
> ><br>
> >Obviously I wasn't at the meetup, so I may be missing some context
here,<br>
> >but can you answer some questions please?<br>
> ><br>
> >- Is the scope for heat-translator only tosca simple-profile,
or also the<br>
> >   original more heavyweight tosca too?<br>
> ><br>
> >- If it's only tosca simple-profile, has any thought been given
to moving<br>
> >   towards implementing support via a template parser plugin,
rather than<br>
> >   baking the translation into the client?<br>
> <br>
> One idea we discussed at the meetup was to use the template-building
code<br>
> that we now have in Heat for building the HOT output from the translator
-<br>
> e.g. the translator would produce ResourceDefinition objects and add
them to<br>
> a HOTemplate object.<br>
> <br>
> That would actually get us a long way toward an implementation of
a template<br>
> format plugin (which basically just has to spit out ResourceDefinition<br>
> objects). So maybe that approach would allow us to start in<br>
> python-heatclient and easily move it later into being a full-fledged<br>
> template format plugin in Heat itself.<br>
> <br>
> >While I see this effort as valuable, integrating the translator
into the<br>
> >client seems the worst of all worlds to me:<br>
> ><br>
> >- Any users/services not intefacing to heat via python-heatclient
can't use it<br>
> <br>
> Yep, this is a big downside (although presumably we'd want to build
in a way<br>
> to just spit out the generated template that can be used by other
clients).<br>
> <br>
> On the other hand, there is a big downside to having it (only) in
Heat also<br>
> - you're dependent on the operator deciding to provide it.<br>
> <br>
> >- You prempt the decision about integration with any higher level
services,<br>
> >   e.g Mistral, Murano, Solum, if you bake in the translator
at the<br>
> >   heat level.<br>
> <br>
> Not sure I understand this one.<br>
<br>
I meant if non-simple TOSCA was in scope, would it make sense to bake the<br>
translation in at the heat level, when there are aspects of the DSL which<br>
we will never support (but some higher layer might).<br>
<br>
Given Sahdev's response saying simple-profile is all that is currently
in<br>
scope, it's probably a non-issue, I just wanted to clarify if heat was
the<br>
right place for this translation.<br>
<br>
Steve<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>