<div dir="ltr">Hi Lakshminarayanan,<div><br></div><div>I believe the extensions you proposed will extend HOT software components usability. In general I have only one concern related to components naming. In your examples you have software components like install_mysql (you got it from Steve's example) and configure_app. </div>
<div>I would say, that these components are not software components, but some actions on software components. This is a small deviation from declarative approach as in general declarative objects more or less independent while actions are naturally have some sequence. For example your configure_app should not be executed before install_app and technically it is the same component on different stages. I don't know what is inside puppet manifest in configure_app but it might contain app installation phase or might not.</div>
<div><br></div><div>From my perspective it will be better to add some concepts of actions for components and have some predefined actions like pre_install, install, post_install and probably some custom actions. This will be more clear approach then declaring action as a software component. This is quite typical approach in different PaaS solutions. </div>
<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 8:08 AM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.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="HOEnZb"><div class="h5"><br>
On Oct 28, 2013, at 9:49 AM, Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>> wrote:<br>
<br>
> On Mon, Oct 28, 2013 at 02:33:40PM +0000, Randall Burt wrote:<br>
>><br>
>> On Oct 28, 2013, at 8:53 AM, Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>><br>
>> wrote:<br>
>><br>
>>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote:<br>
>>>> A few us at IBM studied Steve Baker's proposal on HOT Software<br>
>>>> Configuration. Overall the proposed constructs and syntax are great -- we<br>
>>>> really like the clean syntax and concise specification of components. We<br>
>>>> would like to propose a few minor extensions that help with better<br>
>>>> expression of dependencies among components and resources, and in-turn<br>
>>>> enable cross-vm coordination. We have captured our thoughts on this on the<br>
>>>> following Wiki page<br>
>>>><br>
>>>> <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response</a><br>
>>><br>
>>> Thanks for putting this together.  I'll post inline below with cut/paste<br>
>>> from the wiki followed by my response/question:<br>
>>><br>
>>>> E2: Allow usage of component outputs (similar to resources):<br>
>>>> There are fundamental differences between components and resources...<br>
>>><br>
>>> So... lately I've been thinking this is not actually true, and that<br>
>>> components are really just another type of resource.  If we can implement<br>
>>> the software-config functionality without inventing a new template<br>
>>> abstraction, IMO a lot of the issues described in your wiki page no longer<br>
>>> exist.<br>
>>><br>
>>> Can anyone provide me with a clear argument for what the "fundamental<br>
>>> differences" actually are?<br>
>>><br>
>>> My opinion is we could do the following:<br>
>>> - Implement software config "components" as ordinary resources, using the<br>
>>> existing interfaces (perhaps with some enhancements to dependency<br>
>>> declaration)<br>
>>> - Give OS::Nova::Server a components property, which simply takes a list of<br>
>>> resources which describe the software configuration(s) to be applied<br>
>><br>
>> I see the appeal here, but I'm leaning toward having the components define the resources they apply to rather than extending the interfaces of every compute-related resource we have or may have in the future. True, this may make things trickier in some respects with regard to bootstrapping the compute resource, but then again, don't most configuration management systems work on active compute instances?<br>

><br>
> What "every" though?  Don't we have exactly one compute resource,<br>
> OS::Nova::Server?  (I'm assuming this functionality won't be available via<br>
> AWS compatible Instance resource)<br>
<br>
</div></div>Yes, I suppose it wouldn't do to go extending the AWS compatibility interface with this functionality, so I withdraw my concern.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Steve<br>
><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>
<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>