>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).
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. 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. 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. Thanks, Georgy On Mon, Oct 28, 2013 at 1:48 PM, Mike Spreitzer <mspre...@us.ibm.com> wrote: > Steve Baker <sba...@redhat.com> wrote on 10/28/2013 04:24:30 PM: > > > > On 10/29/2013 02:53 AM, Steven Hardy wrote: > > > ... > > > > Can anyone provide me with a clear argument for what the "fundamental > > > differences" actually are? > > ... > > > Since writing those proposals my thinking has evolved too. I'm currently > > thinking it would be best to implement software configuration resources > > rather than create a new component construct. > > 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? > > Thanks, > Mike > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Technical Program Manager, Cloud and Infrastructure Services, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev