[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