<div dir="ltr">><span style="font-family:monospace">A component is implemented by a bit of user code (and/or other sorts of instructions) >embedded in or referenced by a template, with no fixed API and not invoked with Keystone >credentials.  We desire the heat engine to invoke operations on resources; we do not desire >the heat engine to invoke components (the VMs do that themselves, via whatever >bootstrapping mechanism is used).</span><div>
<span style="font-family:monospace"><br></span></div><div><font face="monospace">I believe we had a discussion about difference between declarative approach and workflows. A component approach is consistent with declarative format as all actions\operations are hidden inside the service. If you want to use actions and operations explicitly you will have to add a workflows specific language to HOT format. You will need to have some conditions and other control structures. </font></div>
<div><font face="monospace"><br></font></div><div><font face="monospace">I also want to highlight that in most of examples on wiki pages there are actions instead of components. Just check names: install_mysql, configure_app.</font></div>
<div><font face="monospace"><br></font></div><div><font face="monospace">I think you revealed the major difference between resource and component. While the first has a fixed API and Heat already knows how to work with it, components are not determined and Heat does not know what this component actually does. I remember the first draft for Software components and it had a specific examples for yum invocation for package installation. This is a good example of declarative component. When scripts and recipes appeared a component definition was blurred.  </font></div>
<div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Thanks,</font></div><div><font face="monospace">Georgy</font></div><div><font face="monospace"><br></font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 1:48 PM, Mike Spreitzer <span dir="ltr"><<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt><font>Steve Baker <<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>> wrote on 10/28/2013
04:24:30 PM:<div class="im"><br>
<br>
> On 10/29/2013 02:53 AM, Steven Hardy wrote:<br></div>
> > ...<div class="im"><br>
> > Can anyone provide me with a clear argument for what the "fundamental<br>
> > differences" actually are?<br></div>
> ...<div class="im"><br>
> Since writing those proposals my thinking has evolved too. I'm currently<br>
> thinking it would be best to implement software configuration resources<br>
> rather than create a new component construct.<br>
</div></font></tt>
<br><tt><font>Please pardon the newbie question, but I do not understand.
 A resource type is implemented in OpenStack code --- a part of Heat
that calls a fixed service API that expects Keystone credentials.  A
component is implemented by a bit of user code (and/or other sorts of instructions)
embedded in or referenced by a template, with no fixed API and not invoked
with Keystone credentials.  We desire the heat engine to invoke operations
on resources; we do not desire the heat engine to invoke components (the
VMs do that themselves, via whatever bootstrapping mechanism is used).
 So yes, I do see fundamental differences.  What am I missing?</font></tt>
<br>
<br><tt><font>Thanks,</font></tt>
<br><tt><font>Mike</font></tt><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>