Make Heat software configuration action-aware

Registered by Thomas Spatzier

With the current design, "software components" defined thru SoftwareConfig resources allow for only one config (e.g. one script) to be specified. Typically, however, a software component has a lifecycle that is hard to express in a single script. For example, software must be installed (created), there should be support for suspend/resume handling, and it should be possible to allow for deletion-logic. This is also in line with the general Heat resource lifecycle.

A proposal for an “lifecycle action aware” software config could look like:

 my_sw_config:
   type: OS::Heat::SoftwareConfig
   properties:
     configs:
       create: # the hook for software install
       suspend: # hook for suspend action
       resume: # hook for resume action
       delete: # hook for delete action
       my_own_stuff: # allow for any custom config hook

I.e. the SoftwareConfig resource would allow for defining several configurations for different lifecycle actions of the corresponding SoftwareDeployment at runtime. The handling will be done by an in-instance hook into os-collect-config. For Heat's default resource lifecycle actions (create, delete, suspend, resume) handling logic can be implemented in a generic hook. For any custom configurations ('my_own_stuff') users will have to provide their own hooks with the necessary logic.

Blueprint information

Status:
Complete
Approver:
Zane Bitter
Priority:
Medium
Drafter:
Thomas Spatzier
Direction:
Approved
Assignee:
Thomas Spatzier
Definition:
Approved
Series goal:
Accepted for juno
Implementation:
Implemented
Milestone target:
milestone icon 2014.2
Started by
Thomas Spatzier
Completed by
Zane Bitter

Related branches

Sprints

Whiteboard

(thomas-spatzier) I would propose to extend the current resource OS::Heat:SoftwareConfig instead of implementing a new one (OS::Heat::ActionAwareConfig) - we already have a number of *Config resources, so yet another one would be even more confusing to users.
This would basically mean to extend the properties schema of the resource. When doing this, we have to take care of existing properties to not break existing users. We could make use of the new "exclusive properties schema" feature being implemented and maybe have two sets of properties that can be used.

Gerrit topic: https://review.openstack.org/#q,topic:bp/action-aware-sw-config,n,z

Addressed by: https://review.openstack.org/98742
    Action-aware software config specification

You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.
(thomas-spatzier) I had a quick discussion last week with Zane on this, so thought it would be ok. I will talk to Zane and ask him to look at this BP.

(thomas-spatzier) 20140806 - updated definition status and set milestone target since spec got approved recently.

Addressed by: https://review.openstack.org/112952
    Add OS::Heat::SoftwareComponent resource

Addressed by: https://review.openstack.org/112953
    Extend software_configs API for SoftwareComponent

Addressed by: https://review.openstack.org/112954
    Enable SoftwareDeployment for SoftwareComponent

Addressed by: https://review.openstack.org/113259
    Enhance SoftwareComponent property validation

Addressed by: https://review.openstack.org/113260
    Validate SoftwareDeployment with SoftwareComponent

Addressed by: https://review.openstack.org/129589
    Fix support status for OS::Heat::SoftwareComponent

(?)

Work Items

Work items:
Extend SoftwareConfig resource property schema: TODO
Implement any necessary logic in SoftwareConfig resource (might not be necessary since SoftwareConfig is a passive store): TODO
Extend SoftwareDeployment resource to pass additional properties needed for action-awereness: TODO
Implement in-instance hook (or extend existing hook to be action aware: TODO

This blueprint contains Public information 
Everyone can see this information.