Open Stack

On Oct 28, 2013, at 9:49 AM, Steven Hardy <shardy at 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 <shardy at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev