Open Stack

On Dec 4, 2013, at 4:06 PM, "Fox, Kevin M" <kevin.fox at pnnl.gov>
 wrote:

> What is the difference between Heater, Cloudify (http://appcatalog.cloudifysource.org/#/?tumblr)

Cloudify is a Java based open source cloud management tool from Gigaspaces. Cloudify developers are part of the Solum project as well, and are supporting the effort.

> and Murano (https://wiki.openstack.org/wiki/Murano)

Murano is a Stackforge project that has recently pivoted into something I would describe as an app catalog system. I am interested in it from a Solum perspective.

> If Heater is intended to be a subset of Cloudify/Murano

I think that Heater and Murano are complimentary, and that Murano could potentially leverage Heater when it takes form. This possibility should be discussed with the Murano contributors prior to drawing any further conclusions.

Note that Heater's focus in much more narrow than Murano's.

> that they both would use, it might be good to start off like the Solum folks are?

I have participated in leading Solum through a process similar to the #1 option proposed below by Tim Schnell. That may be a bit more foolling around than is really needed for this. My vote would be for starting with option #2 (the easiest one), and transitioning to #3 if the code review process seems restrictive, or if the core team for Heat feels it's too much of a burden to do the reviews.

Adrian

> 
> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev