[openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator
Thomas Spatzier
thomas.spatzier at de.ibm.com
Tue Sep 23 10:02:08 UTC 2014
Excerpts from Steven Hardy's message on 23/09/2014 11:37:42:
<snip>
> >
> > 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list