<div dir="ltr">Hi Thomas,<div>Can you share some documentation of what you're doing right now with TOSCA-compliant layer?</div><div>We would like to join to this effort.</div><div><br></div><div>Thanks,</div><div>Dmitry</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 10:38 AM, Thomas Spatzier <span dir="ltr"><<a href="mailto:thomas.spatzier@de.ibm.com" target="_blank">thomas.spatzier@de.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpt from Zane Bitter's message on 26/03/2014 02:26:42:<br>
<br>
> From: Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Date: 26/03/2014 02:27<br>
> Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?<br>
><br>
<br>
<snip><br>
<div class=""><br>
> > Cloud administrators are usually technical guys that are capable of<br>
> > learning HOT and writing YAML templates. They know exact configuration<br>
> > of their cloud (what services are available, what is the version of<br>
> > OpenStack cloud is running) and generally understands how OpenStack<br>
> > works. They also know about software they intent to install. If such<br>
guy<br>
> > wants to install Drupal he knows exactly that he needs HOT template<br>
> > describing Fedora VM with Apache + PHP + MySQL + Drupal itself. It is<br>
> > not a problem for him to write such HOT template.<br>
><br>
> I'm aware that TOSCA has these types of constraints, and in fact I<br>
> suggested to the TOSCA TC that maybe this is where we should draw the<br>
> line between Heat and some TOSCA-compatible service: HOT should be a<br>
> concrete description of exactly what you're going to get, whereas some<br>
> other service (in this case Murano) would act as the constraints solver.<br>
> e.g. something like an image name would not be hardcoded in a Murano<br>
> template, you have some constraints about which operating system and<br>
> what versions should be allowed, and it would pick one and pass it to<br>
> Heat. So I am interested in this approach.<br>
<br>
</div>I can just support Zane's statements above. We are working on exactly those<br>
issues in the TOSCA YAML definition, so it would be ideal to just<br>
collaborate on this. As Zane said, there currently is a thinking that some<br>
TOSCA-compliant layer could be a (maybe thin) layer above Heat that<br>
resolves a more abstract (thus more portable) template into something<br>
concrete, executable. We have started developing code (early versions are<br>
on stackforge already) to find out the details.<br>
<div class=""><br>
><br>
> The worst outcome here would be to end up with something that was<br>
> equivalent to TOSCA but not easily translatable to the TOSCA Simple<br>
> Profile YAML format (currently a Working Draft). Where 'easily<br>
> translatable' preferably means 'by just changing some names'. I can't<br>
> comment on whether this is the case as things stand.<br>
><br>
<br>
</div>The TOSCA Simple Profile in YAML is a working draft at the moment, so we<br>
are pretty much open for any input. So let's see to get the right folks<br>
together and get it right. Since the Murano folks have indicated before<br>
that they are evaluating the option to join the OASIS TC, I am optimistic<br>
that we can get the streams together. Having implementation work going on<br>
here in this community in parallel to the standards work, and both streams<br>
inspiring each other, will be fun :-)<br>
<br>
<br>
Regards,<br>
Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>