Difference between revisions of "Heat/Blueprints/hot-software-config-42"
m (→Use case) |
m (→Updating the guest Metadata) |
||
Line 41: | Line 41: | ||
=== Updating the guest Metadata === | === Updating the guest Metadata === | ||
− | + | So we want to create a resource (server) then step by step modify it. This is a resource that | |
− | This could be implemented using heat-python client or internally. | + | updates a resource's metadata on creation/update. |
+ | |||
+ | This could be implemented using heat-python client or internally. To make sure that we don't progress | ||
+ | until the config is applied we need to have an option signal built in (see the "wait_for_signal"). | ||
+ | (we could call the "resource" property "hosted_on", not a biggie to me). | ||
my_conf: | my_conf: | ||
Line 72: | Line 76: | ||
* It includes a signalling option | * It includes a signalling option | ||
* It does not need manual referencing from the server | * It does not need manual referencing from the server | ||
+ | * It could even be implemented with python-heatclient | ||
Cons: | Cons: |
Revision as of 23:43, 15 October 2013
Contents
HOT Software Config
--asalkeld (talk) 21:10, 16 October 2013 (UTC)
NOTE: This specification is still under discussion and has not been endorsed by the heat project.
Background
So there are 2 other software configuration specs and I like aspects of them, but would like to propose some alternatives for consideration.
https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
I am not a fan of the separation of component and resource, I think this is confusing from a user and will complicate the parser in heat.
I also think where possible Heat should be simply a way to orchestrate resources which are implemented elsewhere. i.e. the resources are actually REST resources.
Use case
People have the following problems with really complex applications.
conf1: hosted_on: serverA conf2: hosted_on: serverB depends_on: conf1 conf3: hosted_on: serverA depends_on: conf2
We want the following order:
- servers first
- conf1 (on serverA)
- conf2 (on serverB)
- conf3 (on serverA)
We _could_ achieve this with wait conditions, but it is complicated and error prone to create the templates. and we want to encourage user adoption, not drive people mad creating templates.
Updating the guest Metadata
So we want to create a resource (server) then step by step modify it. This is a resource that updates a resource's metadata on creation/update.
This could be implemented using heat-python client or internally. To make sure that we don't progress until the config is applied we need to have an option signal built in (see the "wait_for_signal"). (we could call the "resource" property "hosted_on", not a biggie to me).
my_conf: type: OS::Heat::MetadataPatch properties: wait_for_signal: true timeout: 2400 resource: {Ref: my_server} Metadata: foo: bla
when this resource is created it updates "my_server"'s metadata with the following:
my_server: .... Metadata: previous_data: look: it's still here foo: bla OS::Heat::updates: - signal_url: <url_to_post_to>
then it's the job of the guest tools to call "OS::Heat::updates/signal_url"
Pros:
- It does what's on the can (updates metadata)
- It is a normal resource with normal dependencies
- It includes a signalling option
- It does not need manual referencing from the server
- It could even be implemented with python-heatclient
Cons:
- needs some updates to guest tools
Create a new Software Configuration as-a-service
So first off this is not re-doing software configuration. This is providing a REST api on top of existing tools so that heat can just use a python-client lib like it normally does. The section below shows some examples (ssh & ansible). This could be within the Heat program but a different git repo.
Using ssh to configure
Some people love this approach, others hate it. This could be a resource that allows people to choose their poison.
- this could be implemented as a separate service
- this could be ansible as a service
- this could be used to create puppet/chef resources (ssh in run puppet/chef commands)
If you are concerned about managing ssh keys, we can use Barbican for that.
my_conf: type: OS::Heat::Ssh properties: resource: {Ref: my_server} ssh_key: {Ref: my_server_key} commands: - logger "hello from afar"
Pros:
- It does what's on the can (ssh)
- It is a normal resource with normal dependencies
- When it's create_complete is done you know the config is applied
- you don't have to poll the metadata server continuously
Cons:
- it's connecting in