Software Coordination Provider

Registered by Jeff Sloyer on 2013-06-27

Overview:
This blueprint handles the python resource provider for the Heat Engine to be able to parse a HOT template and configure software on an instance.
Purpose of this blueprint is to allow for a clean, declarative way of defining software components to be hosted on compute instances in HOT templates. In contrast to current cfn templates, where software-related metadata is mangled into compute instance resource definitions, the goal is to separate software metadata into seperate resources and have them related to instances via a hosted_on relation. The compute instance itself should then only contain bare minimum metadata to get the instance activated.

What is missing/what are we trying to solve:
Currently in Heat there is a gap in configuring complex and larger software systems. For example sharing a username, password, or database dynamically at deploy time does not exist in Heat right now. It is possible to accomplish this with cfn signaling but it is messy and complex. We wish to simply this.

Goal:
A user wants to deploy a wordpress application and a mysql server. The user does not want to deploy these products in serial and does not want to have global properties for these servers. Ideally the user wants the database server and application silo'ed from each other and each server define what it provides and what the other requires.

Use cases:
-Define a HOT template with a single software component such as wordpress hosted on a compute instance
-Define a HOT template with two software components (web app and DB) hosted on two compute instances that depend on each other
-Deploy a HOT template with software component definitions

Blueprint information

Status:
Complete
Approver:
Steven Hardy
Priority:
High
Drafter:
Jeff Sloyer
Direction:
Approved
Assignee:
Steve Baker
Definition:
Obsolete
Series goal:
None
Implementation:
Started
Milestone target:
None
Started by
Steve Baker on 2013-11-17
Completed by
Steve Baker on 2013-11-19

Related branches

Sprints

Whiteboard

Wiki page with more details and design considerations:
https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider

Additional etherpad for discussion
https://etherpad.openstack.org/software-configuration-provider

travt:
A question? How do the provider get on the instance to start with. For example, the chef agent. Is it assumed that the chef software if pre-installed? Or, will the resource providers support a way to install their required software on the image at boot time?

jsloyer:
To keep a clean approach the "agent" either chef or puppet or whatever would be installed at boot time so we can continue to utilize the clean JEOS images.

(shardy): As discussed with tspatzier on IRC, this seems like a good thing, but we have way too many BPs for h3, so bumping to heat-future (Icehouse) - ideally I'd like to focus on getting core HOT template functionality working for Havana, then we can have a session on this feature at summit and work on the implementation in early Icehouse.

(stevebaker) I'm assigning this to me for now just to do some POC development

(stevebaker) I'm obsoleting this, blueprint hot-software-config is essentially a duplicate.

(?)

Work Items