Open Stack

On 12/04/2013 04:34 PM, Tim Schnell wrote:
> 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.
>

You likely want the current heat-core on this team as well, to help 
provide guidance about how we operate in the Orchestration program. But 
yes, the core team is strained already processing existing review 
workloads and can't handle a high-velocity change new code base very 
easily.  The long term solution to this problem is for more folks to 
provide reviews and join the heat core team.  But that doesn't help the 
heatrr case.

Regards
-steve

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/ef922dba/attachment.html>