Open Stack

What is the difference between Heater, Cloudify (http://appcatalog.cloudifysource.org/#/?tumblr) and Murano (https://wiki.openstack.org/wiki/Murano)

If Heater is intended to be a subset of Cloudify/Murano that they both would use, it might be good to start off like the Solum folks are?

Thanks,
Kevin
________________________________________
From: Tim Schnell [tim.schnell at RACKSPACE.COM]
Sent: Wednesday, December 04, 2013 3:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat] Heater Proposal

Hi Heaters,

We would like to start a dialog on the general direction of the proposed Heater project:
blueprint: https://blueprints.launchpad.net/heat/+spec/heat-template-repo
wiki: https://wiki.openstack.org/wiki/Heat/htr

It is important to us to start the discussion early but please note that the wiki is still very much a work-in-progress. I am actively working to clean up the use cases and the API spec is just to generate discussion, I expect it to change based on general consensus.

We currently have 3 options for starting the Heater project:

 1.  Start Heater as a Stackforge project with a different core team that is dedicated to actively working on Heater
 2.  Incubate Heater within the Orchestration umbrella using the existing Heat Core team
 3.  Incubate Heater with the Orchestration umbrella, but create a sub-project team responsible for reviewing and +2s

The idea behind creating a separate core team either via Stackforge or an Orchestration sub-project is so that the people actively working on Heater can review and iterate more quickly through code revisions than dumping Heater code through the already strained Heat review pipeline.

We are still ironing out the definition of a schema for Heater based on the existing use cases in the wiki and we would very much appreciate any input with regards to the existing use cases or proposed API spec. In particular, it is starting to become apparent that a few of the defined schema are not necessarily related to Heater specifically and may make good candidates to start a separate discussion on inclusion in the HOT specification.

The following things, specifically, would add value to the HOT specification in general (copied from the wiki if you need further context):

application:
   name: Wordpress
   version: 3.6.1
   flavor: Single Linux server with WordPress 3.6.1 and MySQL 5.5
   weight: 3
 icons:
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-tattoo.png
   type: default
 - href: https://600861890ddb34a8670a-744765205721eed93c384dae790e86aa.ssl.cf2.rackcdn.com/wordpress-icon-20x20.png
   type: small
 keywords:
 - wordpress
 - mysql

documentation:
   abstract:
     some abstract...
   guide:
     This blueprint includes a single server running Wordpress with Varnish.
     This blueprint's performance has not been measured.
   instructions:
     If you're new to WordPress, the
     documentation will step you through the process of logging into the
     admin panel, customizing your blog, and changing your theme.

Keywords has already been the subject of another mailing list conversation so let's ignore that one for the moment. If there is general consensus that we should at least discuss application, icons, and documentation as possible candidates for the HOT syntax then I will start a separate mailing list thread to detail out the use cases.

The original thought was, other things like template versioning information and keystone roles for permissions are very obviously related to Heater. Heater will use those things to make decisions about how it works. But application information, icons and documentation are not things that Heater cares about. Heat also does not care about these things but the downstream user interface does care about these things and a human looking at the Heat template would be able to gather valuable information from these things as well.

Obviously, the actual structure and use cases for these things would need to be vetted before inclusion in the HOT syntax but let's discuss the more general idea that the HOT syntax should include things that Heat (or Heater) does not care about but can prove to add real value to the user experience at some point in a user's interaction with Heat.

Thanks,
Tim