Heat/Blueprints/hot-software-config-spec
Background
This page presents a work-in-progress design for the HOT software configuration feature. It should be seen as an evolution a previous hot-software-config proposal, but factoring in result of design discussion at the recent OpenStack summit in Hong Kong. This refined proposal is captured as a new wiki page for readability reasons. Once the design is finalized, we will consolidate the various wiki pages into a single one.
Discussions page: https://wiki.openstack.org/wiki/Talk:Heat/hot-software-config-WIP
Requirements
A number of requirements have been stated during design discussions, and they are also captures in the design summit etherpad. The most important ones to be addressed by this design proposal are summarized below again.
- Composability and re-use: It must be possible to define software components once and compose and re-use them in different contexts without duplicating definitions.
- Separation of component definitions and deployment: It must be possible to define multiple deployments of a software component, e.g. a software component defined once must be able to be deployed on different servers in a template.
- Software components as stateful entities: It must be possible to track state of software components, i.e. whether a software deployment is in progress, has completed, or has failed. It must be possible to retrieve outputs (attributes) of software components.
- Ability to express dependencies between software components: It must be possible to define dependencies between software component, e.g. that input for one component is obtained from output of another component.
High level overview
The following figure (TBD) shows a high level overview of the design idea. Software components are defined in a separate file that can be referenced from templates that want to make use of the respective software component definition. The component definition defines inputs (configurable parameters) and outputs of the software component, it points to the automation like Chef, Puppet or scripts for doing the actual software configuration, and it includes specifics for the respective automation being used (e.g. chef specific parameters).
A Software Deployment resource in a HOT template represents one specific use of the software component, i.e. a concrete deployment on a server. There can be multiple deployments of the same software component, e.g. on two servers, which would be modeled as two separate software deployment resources.
