Jump to: navigation, search

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

Line 21: Line 21:
  
 
= Software Deployment modeling in a HOT template =
 
= Software Deployment modeling in a HOT template =
TBD
+
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
 
  heat_template_version: 2013-05-23
 
   
 
   
 
  resources:
 
  resources:
 
 
   mysql:
 
   mysql:
     type: my::mysql
+
     type: OS::Heat::SoftwareDeployment
 
     properties:
 
     properties:
 +
      component: http://www.example.com/hot/components/MySQL.yaml
 
       server: { get_resource: db_server }
 
       server: { get_resource: db_server }
 
       params:
 
       params:
Line 42: Line 42:
 
       flavor: m1.small
 
       flavor: m1.small
  
TBD
+
The <code>mysql</code> resource in the snippet above is of type <code>OS::Heat::SoftwareDeployment</code> and represents a deployment of MySQL on a server. The <code>component</code> property of the resource points to the component definition file (see below) that contains the actual details of the component. The <code>server</code> property is a reference to the server on which the software will be installed. The server itself is modeled as the <code>db_server</code> resource in the template.
 +
 
 +
== Design alternative ==
 +
In the proposal above, we assume a generic SoftwareDeployment resource implementation, that is actually quite similar to the existing provider template resource implemenation. The referenced component definition (MySQL.yaml in the example above) is like a nested template. An alternative design would be to just use the existing provide template resource (with the necessary enhancements), defining a name of, for example, <code>My::Software::MySQL</code> as type of resource, and then having an environment file map that resource type to the respective component definition YAML file.
 +
 
 +
Pros: closer to the current provider template concept
 +
Cons: less obvious modeling of "Software Deployment"; additional file (environment) required; special handling that we might need for the SoftwareDeployment resource (to be defined) would be implemented in the generic provide template resource.

Revision as of 14:46, 11 November 2013

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.

HOT-software-config-overview.png

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: OS::Heat::SoftwareDeployment
    properties:
      component: http://www.example.com/hot/components/MySQL.yaml
      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 OS::Heat::SoftwareDeployment and represents a deployment of MySQL on a server. The component property of the resource points to the component definition file (see below) that contains the actual details of the component. 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.

Design alternative

In the proposal above, we assume a generic SoftwareDeployment resource implementation, that is actually quite similar to the existing provider template resource implemenation. The referenced component definition (MySQL.yaml in the example above) is like a nested template. An alternative design would be to just use the existing provide template resource (with the necessary enhancements), defining a name of, for example, My::Software::MySQL as type of resource, and then having an environment file map that resource type to the respective component definition YAML file.

Pros: closer to the current provider template concept Cons: less obvious modeling of "Software Deployment"; additional file (environment) required; special handling that we might need for the SoftwareDeployment resource (to be defined) would be implemented in the generic provide template resource.