<div dir="ltr">Hi Steve,<div><br></div><div>I am sorry for my confusing message.</div><div>Just for clarification, I am against adding new abstracts to the HOT template. I just wanted to highlight that in Lakshminarayana proposal there are multiple steps which represent the same component in different stages. This might be confusing, because in you initial proposal you refer one component section for the whole component description, if I am not mistaken.</div>
<div><br></div><div>Thanks</div><div>Georgy</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 12:23 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">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>
</div>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>
<div class="im"><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>
</div>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>
<div class="im"><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>
</div>A resource doesn't have a fixed API as such - it has flexible, user-definable<br>
interfaces (inputs/properties and outputs/attributes)<br>
<div class="im"><br>
> components are not determined and Heat does not know what this component<br>
> actually does.<br>
<br>
</div>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>
<div class="im"><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>
</div>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>
<div class="HOEnZb"><div class="h5"><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><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>