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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
