Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Sahdev P Zala]

Thanks all for a good discussion. 

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.

Thanks!


Regards, 
Sahdev Zala 
IBM SWG Standards Strategy 
Durham, NC 
(919)486-2915 T/L: 526-2915 



From:   Steven Hardy 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   09/23/2014 05:46 AM
Subject:    Re: [openstack-dev] [Heat] Request for python-heatclient 
project to adopt heat-translator



On Fri, Sep 19, 2014 at 06:54:27PM -0400, Zane Bitter wrote:
> 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.

I meant if non-simple TOSCA was in scope, would it make sense to bake the
translation in at the heat level, when there are aspects of the DSL which
we will never support (but some higher layer might).

Given Sahdev's response saying simple-profile is all that is currently in
scope, it's probably a non-issue, I just wanted to clarify if heat was the
right place for this translation.

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

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Thomas Spatzier]

Excerpts from Steven Hardy's message on 23/09/2014 11:37:42:

> >
> > 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
levelservices,
> > >   e.g Mistral, Murano, Solum, if you bake in the translator at the
> > >   heat level.
> >
> > Not sure I understand this one.
>
> I meant if non-simple TOSCA was in scope, would it make sense to bake the
> translation in at the heat level, when there are aspects of the DSL which
> we will never support (but some higher layer might).
>
> Given Sahdev's response saying simple-profile is all that is currently in
> scope, it's probably a non-issue, I just wanted to clarify if heat was
the
> right place for this translation.

Yes, so definitely so far the scope if TOSCA simple profile which aims to
be easily mappable to Heat/HOT. Therefore, close integration makes sense
IMO.

Even if the TOSCA community focuses more on features not covered by Heat
(e.g. the "plans" or workflows which would rather map to Mistral), the
current decision would not preempt such movements. An overall TOSCA
description is basically modular where parts like the declarative topology
could be handed to one layer - this is what we are talking about now - and
other parts (like the flows) could go to a different layer.
So if we get there in the future, this "decomposer functionality" could be
addressed on-top of a layer we are working on today.

Hope this helps and does not add confusion :-)

Regards,
Thomas

>
> 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

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Steven Hardy]

On Fri, Sep 19, 2014 at 06:54:27PM -0400, Zane Bitter wrote:
> 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.

I meant if non-simple TOSCA was in scope, would it make sense to bake the
translation in at the heat level, when there are aspects of the DSL which
we will never support (but some higher layer might).

Given Sahdev's response saying simple-profile is all that is currently in
scope, it's probably a non-issue, I just wanted to clarify if heat was the
right place for this translation.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Zane Bitter]

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

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Sahdev P Zala]

Hi Steve, sure. Please see my reply in-line. 

Thanks! 

Regards, 
Sahdev




From:   Steven Hardy 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   09/09/2014 05:55 AM
Subject:    Re: [openstack-dev] [Heat] Request for python-heatclient 
project to adopt heat-translator



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?

Heat-translator is designed to be used to translate any non-Heat templates 
to HOT. However, current development is done for the TOSCA simple-profile 
only and there is no plan to use it for heavyweight TOSCA.

- 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?

At the meetup, Randall and Zane also mentioned that we should dig into the 
plugin and see if that can also be used for TOSCA. However, we all agreed 
that translation is still good to have and if plugin can be used that will 
be another option for TOSCA users.

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

With python-heatclient, translator will just add a command line option 
i.e. something like ‘heat-translator  
' which will provide an output as HOT. The user 
needs to take the translated template and run it with Heat.

- 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.

Hopefully that won't happen. The translator can be a simple integration at 
the client level and provided just as a command line option without any 
added complexity. 

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.

   When the project was started, there was a discussion with Steve Baker 
and others on IRC that initially it is a good idea to provide the 
translator tool to users via python-heatclient and eventually, as the tool 
gets more mature, we can discuss to make it available in Heat engine to 
provide a seamless deployment of translated template.

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).

  The translator project has no dependency on other services and hoping 
for the same in future.


I hope my answers make sense. Please let me know if you have further 
questions.


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

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Sahdev P Zala]

Hi Angus, please see my reply in-line. 

Thanks!

Regards, 
Sahdev




From:   Angus Salkeld 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   09/09/2014 12:25 AM
Subject:    Re: [openstack-dev] [Heat] Request for python-heatclient 
project to adopt heat-translator



Hi

Would the translator ever need to talk to something like Mistral for 
workflow?

   I do not think so. There is no current plan that needs the 
heat-translator to talk to Mistral or other services.

If so does it make sense to hook the translator into heat client.

(this might not be an issue, just asking).

-Angus

On Wed, Sep 3, 2014 at 1:52 AM, 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. 
Below are some of links related to the project, 
https://github.com/stackforge/heat-translator 
https://launchpad.net/heat-translator 
https://blueprints.launchpad.net/heat-translator 
https://bugs.launchpad.net/heat-translator 
http://heat-translator.readthedocs.org/ (in progress)
Thanks! 

Regards, 
Sahdev Zala 
IBM SWG Standards Strategy 
Durham, NC 
(919)486-2915 T/L: 526-2915 

___
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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Steven Hardy]

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?

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

- 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.

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.

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

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Angus Salkeld]

Hi

Would the translator ever need to talk to something like Mistral for
workflow?
If so does it make sense to hook the translator into heat client.

(this might not be an issue, just asking).

-Angus

On Wed, Sep 3, 2014 at 1:52 AM, 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.
>
> Below are some of links related to the project,
>
> *https://github.com/stackforge/heat-translator*
> 
>
> *https://launchpad.net/heat-translator*
> 
>
> *https://blueprints.launchpad.net/heat-translator*
> 
>
> *https://bugs.launchpad.net/heat-translator*
> 
>
> *http://heat-translator.readthedocs.org/*
>  (in progress)
>
> Thanks!
>
> Regards,
> Sahdev Zala
> IBM SWG Standards Strategy
> Durham, NC
> (919)486-2915 T/L: 526-2915
>
>
> ___
> 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

[openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

[Sahdev P Zala]

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. 
Below are some of links related to the project, 
https://github.com/stackforge/heat-translator
https://launchpad.net/heat-translator
https://blueprints.launchpad.net/heat-translator
https://bugs.launchpad.net/heat-translator
http://heat-translator.readthedocs.org/ (in progress)

Thanks! 

Regards, 
Sahdev Zala 
IBM SWG Standards Strategy 
Durham, NC 
(919)486-2915 T/L: 526-2915 ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev