Open Stack

I agree wholeheartedly with everything Mark says below.

On 10/25/2012 01:26 PM, Mark McLoughlin wrote:
> 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.
> 
> 
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>