Open Stack

Angus,

Thanks for your thoughts. As for the EC2 v OpenStack APis, the EC2 API can be stripped out, leaving all functionality of nova
unimpaired. If the same could be true of the AWS Cloud Formation structures, it would make the project easier to consume 
for those with persnickety legal departments.

If the goal is "template based orchestration" as opposed to "build an AWS Cloud Formation implementation" I'm much more interested. 
If there is renewed interest in TOSCA, I am also more interested.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chrisfer at us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986


-----Angus Salkeld <asalkeld at redhat.com> wrote: -----
To: Christopher B Ferris/Waltham/IBM at IBMUS
From: Angus Salkeld <asalkeld at redhat.com>
Date: 10/25/2012 06:39PM
Cc: Mark McLoughlin <markmc at redhat.com>, openstack-dev at lists.openstack.org, openstack-tc at lists.openstack.org
Subject: Re: [openstack-dev] [openstack-tc] Motion to validate Heat's application as incubated project

On 25/10/12 15:44 -0500, Christopher B Ferris wrote:
>+1 to having this discussion on the ML. Thanks for kicking that off, Mark.
>
>Something that I think needs to be weighed is the use of AWS Cloud Formation data structures. Have we considered the licensing implications for those who would want to distribute the code? Is there any intention on retaining alignment? If so, is there concern that we would be leveraging an interface over which we have little control?
>Does it really make sense for OpenStack to essentially endorse AWS Cloud Formation? 
>
>Conceptually, this project makes a lot of sense. It is similar (as I understand) to what HP presented at the Summit with Project Eve, which is based on TOSCA templates. I am quite concerned with the use of AWS Cloud Formation, though, unless we have an explicit license grant that extends to anyone implementing OpenStack Heat.

Do we do that for the ec2 api we use in nova, how is this different?

Note: we have both the AWS and an OpenStack rest API, tho' we still use
the AWS template format.

That aside I think we aim to make our goal "template based orchestration".
CloudFormations just happened to be the most obvious one to choose early on.

Regarding Eve, I really wish they would work with us to get a TOSCA
implementation into heat but it seems to have been implemented in-house (in java).
I believe they want to change to python but there was no talk of opensourcing
their code so this might be a dead end. To me this comes down to
preventing proliferation of duplicate projects (in a similar way as the
monitoring solutions).
If there is no "official/core" project in openstack people go and write their own.
I don't think this is helpful to the broader OpenStack community. Having an
official project in OpenStack that fill a broad enough scope helps build
a community around a single project that can be vibrant/active. Essentially
the official projects become a place holder for new development. It is easier
for users if there is one official project to figure out rather than 3 or 4
to evaluate for each functional area. From a development perspective we all
seem to be constrained on number of developers and we should do all we can
to encourage efficient use of resources. I think we all committed to OpenStack
and honestly don't mind if it is Heat or some other project that gets into
OpenStack we will all rally around it and make it great. But the point is
at least there will be *a* project to rally around.

I'd like the name "core" project dropped infavor of "official" as the word
is loaded (IMO).

-Angus

>
>Cheers,
>
>Christopher Ferris
>IBM Distinguished Engineer, CTO Industry and Cloud Standards
>Member, IBM Academy of Technology
>IBM Software Group, Standards Strategy
>email: chrisfer at us.ibm.com
>Twitter: christo4ferris
>phone: +1 508 234 2986
>
>
>-----Mark McLoughlin <markmc at redhat.com> wrote: -----
>To: Angus Salkeld <asalkeld at redhat.com>
>From: Mark McLoughlin <markmc at redhat.com>
>Date: 10/25/2012 04:30PM
>Cc: openstack-dev at lists.openstack.org, openstack-tc at lists.openstack.org
>Subject: Re: [openstack-dev] [openstack-tc] Motion to validate Heat's application as incubated project
>
>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-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>