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