Jump to: navigation, search

Heat/Blueprints/hot-software-config-42

< Heat
Revision as of 23:43, 15 October 2013 by Asalkeld (talk | contribs) (Updating the guest Metadata)

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:

  1. servers first
  2. conf1 (on serverA)
  3. conf2 (on serverB)
  4. 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