Hi Lakshminarayanan, 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. 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.
>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. Thanks Georgy On Mon, Oct 28, 2013 at 8:08 AM, Randall Burt <randall.b...@rackspace.com>wrote: > > On Oct 28, 2013, at 9:49 AM, Steven Hardy <sha...@redhat.com> wrote: > > > On Mon, Oct 28, 2013 at 02:33:40PM +0000, Randall Burt wrote: > >> > >> On Oct 28, 2013, at 8:53 AM, Steven Hardy <sha...@redhat.com> > >> wrote: > >> > >>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana > wrote: > >>>> A few us at IBM studied Steve Baker's proposal on HOT Software > >>>> Configuration. Overall the proposed constructs and syntax are great > -- we > >>>> really like the clean syntax and concise specification of components. > We > >>>> would like to propose a few minor extensions that help with better > >>>> expression of dependencies among components and resources, and in-turn > >>>> enable cross-vm coordination. We have captured our thoughts on this > on the > >>>> following Wiki page > >>>> > >>>> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > >>> > >>> Thanks for putting this together. I'll post inline below with > cut/paste > >>> from the wiki followed by my response/question: > >>> > >>>> E2: Allow usage of component outputs (similar to resources): > >>>> There are fundamental differences between components and resources... > >>> > >>> So... lately I've been thinking this is not actually true, and that > >>> components are really just another type of resource. If we can > implement > >>> the software-config functionality without inventing a new template > >>> abstraction, IMO a lot of the issues described in your wiki page no > longer > >>> exist. > >>> > >>> Can anyone provide me with a clear argument for what the "fundamental > >>> differences" actually are? > >>> > >>> My opinion is we could do the following: > >>> - Implement software config "components" as ordinary resources, using > the > >>> existing interfaces (perhaps with some enhancements to dependency > >>> declaration) > >>> - Give OS::Nova::Server a components property, which simply takes a > list of > >>> resources which describe the software configuration(s) to be applied > >> > >> 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? > > > > What "every" though? Don't we have exactly one compute resource, > > OS::Nova::Server? (I'm assuming this functionality won't be available > via > > AWS compatible Instance resource) > > Yes, I suppose it wouldn't do to go extending the AWS compatibility > interface with this functionality, so I withdraw my concern. > > > > > Steve > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > 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