[openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config

Steve Baker sbaker at redhat.com
Mon Oct 28 20:24:30 UTC 2013


On 10/29/2013 02:53 AM, Steven Hardy 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
>
> 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?
Since writing those proposals my thinking has evolved too. I'm currently
thinking it would be best to implement software configuration resources
rather than create a new component construct.

To me, a natural consequence of configuration resources would be a
hosted_on property rather than OS::Nova::Server components property, but
I'll elaborate on that elsewhere.



More information about the OpenStack-dev mailing list