Open Stack

So the risks u have just stated do make sense.

But isn't this problem solved by strong leadership saying we will not let people screw over the EC2 apis?

And strong leadership not letting that happen...

Shouldn't the question be what is the right architectural solution, not one that is being done so that people can't "ignore" the EC2 apis.

If the leadership of openstack can't handle this kind of issue (its pretty minor), then we are all screwed :-P

On 4/23/12 11:16 AM, "Russell Bryant" <rbryant at redhat.com> wrote:

On 04/23/2012 10:42 AM, Doug Hellmann wrote:
>
>
> On Mon, Apr 23, 2012 at 8:39 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
>
>     Philipp Wollermann wrote:
>     > What's the advantage of replacing the native EC2 compatibility
>     layer with AWSOME from a user / operator point of view?
>
>     One thing that was mentioned is that the proxy could be run on top of a
>     public cloud that chose to only deploy OpenStack API support.

This makes sense.

> It also makes project management easier, as the people interested in
> maintaining it can focus on the separate repository.

I'm not sure I buy into this, though.  Why is it harder for people that
are interested in EC2 support to work in the existing nova repo?  If
people want to collaborate before pushing into mainline, that can be
done via feature branches, too.

It risks making EC2 development harder, as well.  Pulling it out of nova
completely risks allowing the people that don't care about EC2 to care
even less.  It could make it easier for people to make changes that make
EC2 compatibility harder to maintain.

--
Russell Bryant

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120423/5c0ec79e/attachment.html>