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 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.

Software Deployment modeling in a HOT template

One concrete deployment of a software component (i.e. one instance of the software installed at runtime) is modeled in a HOT template as one resource which points to the software component definition and defines the data flow (inputs as properties, outputs as attributes references from other parts of the template) in the context of the template. The resource fuirther has a reference to the server on which the software gets installed.

heat_template_version: 2013-05-23

resources:
  mysql:
    type: My::Software::MySQL
    properties:
      server: { get_resource: db_server }
      params:
        db_name: { get_param: db_name }
        db_user: { get_param: db_user }
        db_pw: { get_param: db_pw }

  db_server:
    type: OS::Nova::Server
    properties:
      image: F19-x86_64-cfntools
      flavor: m1.small

The mysql resource in the snippet above is of type My::Software::MySQL (which is an arbitrary resource type) and represents a deployment of MySQL on a server. By means of an environment resource mapping, that type name gets bound to a concrete software component definition (see below). The server property is a reference to the server on which the software will be installed. The server itself is modeled as the db_server resource in the template.

The advantage of using an environment mapping of the resource type name of the mysql resource is that the template itself does not point to one concrete software component definition in a hardcoded fashion, but that alternative definitions can be used thru the respective environment mapping as long as they have the same signature (inputs and outputs). For example, this would allow for having one component definition that will work on F19 images and another one that will work on Ubuntu images. Another example is that the current provider template resource implementation can be used (probably without any changes).

Design alternative

As an alternative, we could implement generic SoftwareDeployment resource type (OS::Heat::SoftwareDeployment) and let it point to the software component definition via a property, e.g. a component property:

resources:
  mysql:
    type: OS::Heat::SoftwareDeployment
    properties:
      component: http://www.example.com/hot/components/MySQL.yaml
      server: { get_resource: db_server }
      params:
        # ...

The referenced component definition (MySQL.yaml in the example above) is like a nested template, but the SoftwareDeployment resource could implement specific code (to be defined) that is not necessary in the generic provide template resource.

Pros: more obvious modeling of a "software deployment"; ability to have special code in the SoftwareDeployment resource

Cons: pretty close to provide template concept, but not really the same (which could be confusing); hardcoded pointer to one specific software component definition, which requires change to the template for pointing to an alternative definition.