Difference between revisions of "Heat/Software-Configuration-Provider"
m (→Components and Resources) |
|||
Line 1: | Line 1: | ||
+ | '''Important note: this page is being reworked after discussions at the OpenStack design summit. Updates will be posted soon.''' | ||
+ | |||
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. |
Revision as of 09:28, 11 November 2013
Important note: this page is being reworked after discussions at the OpenStack design summit. Updates will be posted soon.
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
Contents
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