Software Coordination Provider

Registered by Jeff Sloyer

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.

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

Steven Hardy
Jeff Sloyer
Steve Baker
Series goal:
Milestone target:
Started by
Steve Baker
Completed by
Steve Baker

Related branches



Wiki page with more details and design considerations:

Additional etherpad for discussion

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?

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