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@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
