Open Stack

On Wed, 2012-10-24 at 09:07 +1100, Angus Salkeld wrote:
> Dear Member of the OpenStack Technical Committee,
> 
> Following up on Heat's application to the former PPB to be
> incubated that was done in July [1], we would like you to consider a
> motion to validate this application at your next meeting.
> 
> The project's application can be found at [2].
> 
> We would be happy to answer any question you may have about our
> application and hope that you will give a favorable answer to our request.
> 
> [1] http://www.mail-archive.com/openstack@lists.launchpad.net/msg14506.html
> [2] http://wiki.openstack.org/Heat

I know some members of the TC would like to discuss the "widening of
OpenStack's scope"[1] that including Heat implies. IMHO it would be good
to give that subject a thoughtful airing on the mailing list rather than
rush a discussion at the next meeting.

Briefly, my feeling on the "scope" question is that at its core Heat
provides some very straightforward and easy to understand orchestration
features which are a really nice addition to OpenStack.

By orchestration, I mean it gives you the ability to say "run my
Wordpress app" and have the following happen:

  1) The DB server instance is launched, perhaps with user-supplied 
     parameters like the DB admin password passed to the instance via
     user-data
  2) During its startup it reports its IP address back to Heat
  3) Heat sees that the DB has started and launches the Wordpress 
     server with the DB IP address passed via user-data
  4) The Wordpress app configures itself to use the DB and then reports 
     its own IP address back to Heat
  5) Heat uses the IP address to build a URL for the Wordpress server 
     and returns the URL to the user

All of the instructions to Heat about how to orchestrate the launching
of an app are supplied as part of the "run my Wordpress app" request in
the form of a "template" file. If you know AWS CloudFormations, then you
know how this works. Heat borrows heavily from it.

This is a really sweet feature and serves as a great integration point
for all OpenStack APIs. I'd love to see this be accepted into the family
of OpenStack projects.

In considering the incubation proposal, I'd like to see us consider e.g.

  * Is the project a sound technical idea?
  * Does the architecture make sense?
  * Is the service useful to OpenStack operators or users?
  * Are the APIs a good addition to OpenStack APIs?
  * Is the project following OpenStack development processes?
  * Does the project look like it has a healthy future?

There's a whole other discussion about "what is core?", "what is
OpenStack™?", "what services/APIs are required for a cloud to use the
OpenStack name?", etc.

That's a discussion that the TC and Foundation Board need to have (both
separately and together) but I'd hate to see the TC undermine the
progress of a thriving project like Heat because we haven't got our act
together on those questions.

The first question  should be whether we hope to welcome Heat into the
family of OpenStack projects after an incubation period.

The second, later question should be how we classify Heat's role in that
family once it has been incubated.

Cheers,
Mark.