|
|
| (8 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | = HOT Software Config =
| |
| − | --[[User:Angus Salkeld|asalkeld]] ([[User talk:Angus Salkeld|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.
| |
| − |
| |
| − | === Updating the guest Metadata ===
| |
| − |
| |
| − | A resource to patch a resources metadata, something like:
| |
| − | my_conf:
| |
| − | type: OS::Heat::MetadataPatch
| |
| − | properties:
| |
| − | wait_for_signal: true
| |
| − | timeout: 2400
| |
| − | resource: {Ref: my_server}
| |
| − | Metadata:
| |
| − | foo
| |
| − |
| |
| − | when this resource is created it updates "my_server"'s metadata with the following:
| |
| − | my_server:
| |
| − | ....
| |
| − | Metadata:
| |
| − | updates:
| |
| − | my_conf:
| |
| − | foo
| |
| − | signal_url: <url_to_post_to>
| |
| − |
| |
| − | then it's the job of the guest tools to call "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
| |
| − |
| |
| − | === 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 continously
| |
| − |
| |
| − | Cons:
| |
| − | * it's connecting in
| |
