Open Stack

>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 <mspreitz at us.ibm.com> wrote:

> Steve Baker <sbaker at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/eee64c5a/attachment.html>