Jump to: navigation, search

Difference between revisions of "Heat/Blueprints/hot-software-config-42"

(Updating the guest Metadata)
Line 14: Line 14:
 
I am not a fan of the separation of component and resource, I think this is confusing from a user and
 
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.
 
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 ===
 
=== Updating the guest Metadata ===
Line 46: Line 49:
 
Cons:
 
Cons:
 
* needs some updates to guest tools
 
* needs some updates to guest tools
 +
 +
=== Create a new Software 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 ===
 
=== Using ssh to configure ===
Line 68: Line 77:
 
* It is a normal resource with normal dependencies
 
* It is a normal resource with normal dependencies
 
* When it's create_complete is done you know the config is applied
 
* When it's create_complete is done you know the config is applied
* you don't have to poll the metadata server continously
+
* you don't have to poll the metadata server continuously
  
 
Cons:
 
Cons:
 
* it's connecting in
 
* it's connecting in

Revision as of 23:11, 15 October 2013

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:

 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

Create a new Software 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