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
