Difference between revisions of "Heat/Blueprints/hot-software-config-42"
m (→Using ssh to configure) |
(→Updating the guest Metadata) |
||
Line 21: | Line 21: | ||
A resource to patch another resource's metadata, something like: | A resource to patch another resource's metadata, something like: | ||
+ | |||
+ | This could be implemented using heat-python client or internally. | ||
+ | |||
my_conf: | my_conf: | ||
type: OS::Heat::MetadataPatch | type: OS::Heat::MetadataPatch | ||
Line 28: | Line 31: | ||
resource: {Ref: my_server} | resource: {Ref: my_server} | ||
Metadata: | Metadata: | ||
− | foo | + | foo: |
+ | bla | ||
when this resource is created it updates "my_server"'s metadata with the following: | when this resource is created it updates "my_server"'s metadata with the following: | ||
my_server: | my_server: | ||
.... | .... | ||
− | + | Metadata: | |
− | + | foo: | |
− | + | bla | |
− | + | OS::Heat::updates: | |
− | + | - signal_url: <url_to_post_to> | |
− | then it's the job of the guest tools to call "updates | + | then it's the job of the guest tools to call "OS::Heat::updates/signal_url" |
Pros: | Pros: |
Revision as of 23:18, 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.
Updating the guest Metadata
A resource to patch another resource's metadata, something like:
This could be implemented using heat-python client or internally.
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: 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
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