Open Stack

On 28/10/13 14:53, 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?

Here's an argument: Component deployments exist within a server 
resource, so the dependencies don't work in the same way. The static 
part of the configuration has to happen before the server is created, 
but the actual runtime part is created after. So the dependencies are 
inherently circular.

> 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 think to overcome the problem described above, we would also need to 
create a third type of resource. So we'd have a Configuration, a Server 
and a Deployment. (In dependency terms, these are analogous to 
WaitConditionHandle, Server and WaitCondition, or possibly EIP, Server 
and EIPAssociation.) The deployment would reference the server and the 
configuration, you could pass parameters into it get attributes out of 
it, add explicit dependencies on it &c.

What I'm not clear on in this model is how much of the configuration 
needs to be built to go onto the server (in the UserData?) before the 
server is created, and how that would be represented in such a way as to 
inherently create the correct dependency relationship (i.e. get the 
_Server_ as well as the Deployment to depend on the configuration).

> 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

+1 if we can do it.

cheers,
Zane.