|
|
(One intermediate revision 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.
| |
− |
| |
− | 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 ===
| |
− |
| |
− | A resource to patch another resource's metadata.
| |
− | 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:
| |
− | 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
| |
− |
| |
− | 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
| |