Open Stack

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?

> 
> This provides a lot of benefits:
> - Uniformity of interfaces (solves many of the interface-mapping issues you
>  discuss in the wiki)
> - Can use provider resources and environments functionality unmodified
> - Conceptually simple, we don't have to confuse everyone with a new
>  abstraction sub-type and related terminology
> - Resources describing software components will be stateful, as described
>  in (E4), only the states would be the existing resource states, e.g
>  CREATE, IN_PROGRESS == CONFIGURING, and CREATE, COMPLETE ==
>  CONFIG_COMPLETE
> 
> Thoughts?

Completely agree here. So far, I've not seen how components differ from resources save for some name and superficial syntax changes. Ordering component resources can likely be achieved with the existing "depends-on" functionality as well.

> 
> Steve
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev