Jump to: navigation, search

Difference between revisions of "Heat/Software-Configuration-Provider"

(Example)
(Navigating the hot software config related blueprints and wikis has become rather confusing. Based on the apparent blueprint statuses, I've updated this page to refer to the apparent newer spec. Hopefully original authors will confirm / fix")
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
'''Important note: this page is being reworked after discussions at the OpenStack design summit. Updates will be posted soon.'''
 +
 +
'''This page has been replaced by a newer blueprint and specification. This now represents an archive of concepts. See: https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec'''
 +
 
This wiki page page is related to blueprint https://blueprints.launchpad.net/heat/+spec/software-configuration-provider.
 
This wiki page page is related to blueprint https://blueprints.launchpad.net/heat/+spec/software-configuration-provider.
 
Its goal is to give some background information on that blueprint, explain expected benefits from a user (template author) perspective, define requirements for the implementation, and to have initial design consideration for implementation of the referenced blueprint.
 
Its goal is to give some background information on that blueprint, explain expected benefits from a user (template author) perspective, define requirements for the implementation, and to have initial design consideration for implementation of the referenced blueprint.
Line 22: Line 26:
 
       wordpress: http://www.example.com/my_cookbooks/wordpress.zip
 
       wordpress: http://www.example.com/my_cookbooks/wordpress.zip
 
     # more metadata for chef solo based deployment
 
     # more metadata for chef solo based deployment
  relationships:
+
    relationships:
    hosted_on: my_instance
+
      hosted_on: my_instance
 
   
 
   
 
  resources:
 
  resources:
Line 49: Line 53:
 
== Remarks on some HOT constructs ==
 
== Remarks on some HOT constructs ==
 
=== Components and Resources ===
 
=== Components and Resources ===
The HOT template draft above distinguish between components and resources.  Components make up the actual workload described by a template, while resources respresent that underlying resources required by a workload. Resources are provided as a services by respective resources providers (e.g. a nova compute resource provider implementation).
+
The HOT template draft above distinguishes between components and resources.  Components make up the actual workload described by a template, while resources respresent that underlying resources required by a workload. Resources are provided as a services by respective resources providers (e.g. a nova compute resource provider implementation).
  
 
Templates may be nested, i.e. a template might contain lower level implementation that is referred to more abstractly from within another template.  That is, a template might be a provider for a resources referenced in a higher- level template.
 
Templates may be nested, i.e. a template might contain lower level implementation that is referred to more abstractly from within another template.  That is, a template might be a provider for a resources referenced in a higher- level template.
  
 
=== Relationships between components and resources ===
 
=== Relationships between components and resources ===
Components and resources can have relationships between each other. There can be relations from one component to another component, from a component to a resource, and from one resource to another resource.
+
Components and resources can have relationships between each other. There can be relations from one component to another component, from a component to a resource, and from one resource to another resource. Relationships are defined in the 'relationships' clause of a resource or component definition in the HOT template.
 
 
Relationships generally exist when one component or resource has a requirement against some other component or resource. Therefore, all relationships are defined in the 'requires' clause of a resource or component definition in the HOT template.
 
  
 
  components:
 
  components:
Line 62: Line 64:
 
     # general information
 
     # general information
 
     # ...
 
     # ...
     requires:
+
     relationships:
       # requirements against / relations to other components or resources
+
       # relations to other components or resources
  
 
The orchestration runtime understand three base type of relations:
 
The orchestration runtime understand three base type of relations:
Line 80: Line 82:
 
  components:
 
  components:
 
   comp1:
 
   comp1:
     requires:
+
     relationships:
 
       hosted_on: comp2
 
       hosted_on: comp2
  
 
In the example above, the short notation of a <code>hosted_on</code> relation definition is shown. The key of the relation definition is the relationship type - <code>hosted_on</code> in this example - and the value is the referenced component or resource.
 
In the example above, the short notation of a <code>hosted_on</code> relation definition is shown. The key of the relation definition is the relationship type - <code>hosted_on</code> in this example - and the value is the referenced component or resource.
  
As an alternative to referencing a concrete resource by its ID, it is also possible to denote a resource type (such as os::nova::compute). This would express, that <code>comp1</code> requires to be hosted on a compute instance, but does not give any more constraints on the compute instance. If more constraints need to be expressed, the long notation should be used.
+
As an alternative to referencing a concrete resource by its ID, it is also possible to denote a resource type (such as os::nova::compute). This would express, that <code>comp1</code> needs to be hosted on a compute instance, but does not give any more constraints on the compute instance. If more constraints need to be expressed, the long notation should be used.
  
 
'''2. long notation'''
 
'''2. long notation'''
 
  components:
 
  components:
 
   comp1:
 
   comp1:
     requires:
+
     relationships:
 
       hosted_on_comp2:
 
       hosted_on_comp2:
 
         type: hosted_on
 
         type: hosted_on
Line 97: Line 99:
 
The example above shows the long notation of a <code>hosted_on</code> relation between <code>comp1</code> and <code>comp2</code> - i.e. the same example as used in the short notation earlier.  The name of the relation <code>hosted_on_comp2</code> is an arbitrary name. The type attribute denotes the type of relation. The target attribute references another component or resource.
 
The example above shows the long notation of a <code>hosted_on</code> relation between <code>comp1</code> and <code>comp2</code> - i.e. the same example as used in the short notation earlier.  The name of the relation <code>hosted_on_comp2</code> is an arbitrary name. The type attribute denotes the type of relation. The target attribute references another component or resource.
  
If a generic requirement on a component or resource should be expressed (in contrast to referencing a concrete component or resource by ID), the target attribute would not contain the ID of another component or resource, but it would denote the type of the required resource. It is then the responsibility of the orchestration platform to fulfil the requirement appropriately.
+
If a relationship to a component- or resource type should be expressed (in contrast to referencing a concrete component or resource by ID), the target attribute would not contain the ID of another component or resource, but it would denote the type of the required resource. It is then the responsibility of the orchestration platform to fulfil the requirement appropriately.
  
 
Example:
 
Example:
 
  components:
 
  components:
 
   comp1:
 
   comp1:
     requires:
+
     relationships:
 
       hosted_on_comp2:
 
       hosted_on_comp2:
 
         type: hosted_on
 
         type: hosted_on

Latest revision as of 21:27, 5 February 2014

Important note: this page is being reworked after discussions at the OpenStack design summit. Updates will be posted soon.

This page has been replaced by a newer blueprint and specification. This now represents an archive of concepts. See: https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec

This wiki page page is related to blueprint https://blueprints.launchpad.net/heat/+spec/software-configuration-provider. Its goal is to give some background information on that blueprint, explain expected benefits from a user (template author) perspective, define requirements for the implementation, and to have initial design consideration for implementation of the referenced blueprint.

The goal of the software configuration resource provider item is to allow template authors to declaratively define software components hosted on compute instances and thus establishing software components as first class citizens in HOT templates. In contrast to CFN templates where software related information is mixed into instance metadata and user data (e.g. inlined scripting), we want to clearly separate software component information from infrastructure definition and then express hosting relations of software components to the infrastructure.
The goal is not to introduce different resource providers for different pieces of software, but to have a generic provider that can declaratively configure software using chef, for example, and maybe another provider that allows for using custom scripting (using references to custom scripts).

Discussion Page: https://wiki.openstack.org/wiki/Talk:Heat/Software-Configuration-Provider

Example

Consider a use case where Wordpress should be installed on a single instance and a chef cookbook for doing this configuration should be used. The template author would declare a software component for and declare that it be hosted on a compute instance defined in the sample template:

heat_template_version: 2013-05-23

parameters:
  # parameters for Wordpress and compute instance ...

components:
  wordpress:
    type: OS::Heat::software_config::chef_solo
    cookbooks:
      wordpress: http://www.example.com/my_cookbooks/wordpress.zip
    # more metadata for chef solo based deployment
    relationships:
      hosted_on: my_instance

resources:
  my_instance:
    type: AWS::EC2::Instance
    # details for instance resource ...

The template above defines one component wordpress and one resource my_instance (see Components and Resources for more details on components vs. resources). The component is hosted_on the compute instance resource (see Relationships between components and resources for more details on the relationships section). The provider implementation that is backing up type OS::Heat::software_config::chef_solo knows how to interpret the information inside the wordpress component declaration.
In the cookbooks section, a set of required cookbooks is declared, including references to the respective archives. In the following, more metadata (like roles to be configured) would be given.

The relationships section lists relations of the current component to other components or resources in the template. In the current example, it states that the software component is hosted on a compute instance defined in the sample template. It is also possible to just express a hosting requirement against a specific type of resource (see also Notation of relationship in a HOT template). In any case, the software layer is cleanly separated from the infrastructure layer which enables deployment flexibility later on.

Implementation Requirements

  • The Heat engine should keep track of the state of software components, i.e.
    • A stack should be marked as CREATE_COMPLETE only when all defined software components are in state CREATE_COMPLETE without the template writer having to define explicit wait conditions
    • Stack data (output of heat stack-show command) should contain a representation of software components


Implementation Considerations

The compute instance resource definition does not include any data about the software components hosted on them - i.e. the user does not have to define this in the template. During deployment time it has to be made sure that respective user data or metadata is passed to the instance so that an in-instance agent can take care of configuring software components hosted on an instance.

The in-instance agent has to signal back to the Heat engine when configuration for a software component is done (or has failed) so that the state of the software component in a stack can be updated (see Implementation Requirements). The important point is that this will be done implicitly without the template writer having to define signaling constructs in the template explicitly.

Remarks on some HOT constructs

Components and Resources

The HOT template draft above distinguishes between components and resources. Components make up the actual workload described by a template, while resources respresent that underlying resources required by a workload. Resources are provided as a services by respective resources providers (e.g. a nova compute resource provider implementation).

Templates may be nested, i.e. a template might contain lower level implementation that is referred to more abstractly from within another template. That is, a template might be a provider for a resources referenced in a higher- level template.

Relationships between components and resources

Components and resources can have relationships between each other. There can be relations from one component to another component, from a component to a resource, and from one resource to another resource. Relationships are defined in the 'relationships' clause of a resource or component definition in the HOT template.

components:
  my_component:
    # general information
    # ...
    relationships:
      # relations to other components or resources

The orchestration runtime understand three base type of relations:

  • hosted_on: the defining component is hosted on the referenced component or resource
  • depends_on: the defining component has a general dependency on the referenced component or resource
  • connects_to: the definining component needs to connect to the referenced component or resource. In contrast to depends_on, a connects_to relation generally involves execution of some code to establish the connection

From the base relation types above, the orchestrator can derive a base orchestration flow. For example, a hosting resource has to be created first before a hosted component can be created on-top. For specific processing (e.g. execution of custom code to establish a connection), derived relations can be declared that provide the respective logic.

Notation of relationship in a HOT template

There are two ways for defining a relation in a HOT template:

1. short notation

components:
  comp1:
    relationships:
      hosted_on: comp2

In the example above, the short notation of a hosted_on relation definition is shown. The key of the relation definition is the relationship type - hosted_on in this example - and the value is the referenced component or resource.

As an alternative to referencing a concrete resource by its ID, it is also possible to denote a resource type (such as os::nova::compute). This would express, that comp1 needs to be hosted on a compute instance, but does not give any more constraints on the compute instance. If more constraints need to be expressed, the long notation should be used.

2. long notation

components:
  comp1:
    relationships:
      hosted_on_comp2:
        type: hosted_on
        target: comp2

The example above shows the long notation of a hosted_on relation between comp1 and comp2 - i.e. the same example as used in the short notation earlier. The name of the relation hosted_on_comp2 is an arbitrary name. The type attribute denotes the type of relation. The target attribute references another component or resource.

If a relationship to a component- or resource type should be expressed (in contrast to referencing a concrete component or resource by ID), the target attribute would not contain the ID of another component or resource, but it would denote the type of the required resource. It is then the responsibility of the orchestration platform to fulfil the requirement appropriately.

Example:

components:
  comp1:
    relationships:
      hosted_on_comp2:
        type: hosted_on
        target: os::nova::compute
        constraints:
          arch: x86_64
          cpu:
            greater_or_equal: 2
          memory:
            greater_or_equal: 4GB