<html><body>
<p><font size="2" face="sans-serif">I am wondering on the execution semantics of these components or software config resources with respect to restart or re-execution. Coming from a iterative development and deployment angle, I would like these software config resources to be idempotent. What are your thoughts?</font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">LN</font><br>
<br>
<tt><font size="2">Steven Hardy <shardy@redhat.com> wrote on 10/29/2013 03:23:14 AM:<br>
<br>
> From: Steven Hardy <shardy@redhat.com></font></tt><br>
<tt><font size="2">> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <openstack-dev@lists.openstack.org></font></tt><br>
<tt><font size="2">> Date: 10/29/2013 03:28 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's <br>
> Proposal on HOT Software Config</font></tt><br>
<tt><font size="2">> <br>
> On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote:<br>
> > I believe we had a discussion about difference between declarative approach<br>
> > and workflows. A component approach is consistent with declarative format<br>
> > as all actions\operations are hidden inside the service. If you want to use<br>
> > actions and operations explicitly you will have to add a workflows specific<br>
> > language to HOT format. You will need to have some conditions and other<br>
> > control structures.<br>
> <br>
> Please don't confuse the component/resource discussion further by adding<br>
> all these unrelated terms into the mix:<br>
> <br>
> - Resources are declarative, components aren't in any way more declarative<br>
> <br>
> - The resource/component discussion is unrelated to workflows, we're<br>
> discussing the template level interfaces.<br>
> <br>
> - Adding imperative control-flow interfaces to the template is the opposite<br>
> of a declarative approach<br>
> <br>
> > I also want to highlight that in most of examples on wiki pages there are<br>
> > actions instead of components. Just check names: install_mysql,<br>
> > configure_app.<br>
> <br>
> Having descriptions of the actions required to do configure an application<br>
> is not declarative. Having a resource define the properties of the<br>
> application is.<br>
> <br>
> > I think you revealed the major difference between resource and component.<br>
> > While the first has a fixed API and Heat already knows how to work with it,<br>
> <br>
> A resource doesn't have a fixed API as such - it has flexible, user-definable<br>
> interfaces (inputs/properties and outputs/attributes)<br>
> <br>
> > components are not determined and Heat does not know what this component<br>
> > actually does.<br>
> <br>
> Heat doesn't need to know what a resource or component actually does, it<br>
> needs to know what do do with the inputs/properties, and how to obtain the<br>
> outputs/attributes.<br>
> <br>
> > I remember the first draft for Software components and it<br>
> > had a specific examples for yum invocation for package installation. This<br>
> > is a good example of declarative component. When scripts and recipes<br>
> > appeared a component definition was blurred.<br>
> <br>
> This makes no sense, scripts defining platform specific installation<br>
> methods are the exact opposite of a declarative component.<br>
> <br>
> The blurred component definition you refer to is a very good reason not to<br>
> add a new abstraction IMO - we should focus on adding the functionality via<br>
> the existing, well understood interfaces.<br>
> <br>
> Steve<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>