Open Stack

Why not just use glance?

On 12/04/2013 06: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.
> 
> 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
>