Open Stack

Cristopher,

FYI in regard to "

Its the sort of direction that we tried to steer the GCE
API folks in I
cehouse, though I don't know what they ended up doing

"

We ended up perfectly ok. The project is on Stackforge for some time https://github.com/stackforge/gce-api. It works.
I believe that this is exactly what should be done with EC2 as well. We even considered and tried to estimate it once.

I can tell you even more that we do have lots of AWS Tempest tests specifically to check various compatibility issues in OpenStack. And we've created a number of fixes for proprietary implementation of a cloud based on OpenStack. Some of them are in EC2 layer, some are in nova core.

But anyways, I'm completely convinced that:

1. Any further improvements to EC2 layer should be done after its separation from nova.
2. EC2 should still somehow be supported by OpenStack because as far as I know lots of people use euca2ools to access it.

Best regards,
   Alex Levine

24.04.2014 19:24, Christopher Yeoh пишет:
> On Thu, 24 Apr 2014 09:10:19 +1000
> Michael Still <mikal at stillhq.com> wrote:
>> These seem like the obvious places to talk to people about helping us
>> get this code maintained before we're forced to drop it. Unfortunately
>> we can't compel people to work on things, but we can make it in their
>> best interests.
>>
>> A followup question as well -- there's a proposal to implement the
>> Nova v2 API on top of the v3 API. Is something similar possible with
>> EC2? Most of the details of EC2 have fallen out of my brain, but I'd
>> be very interested in if such a thing is possible.
> So there's sort of a couple of ways we suggested doing a V2 API on top
> of V3 long term. The current most promising proposal (and I think
> Kenichi has covered this a bit in another email) is a very thin layer
> inside the Nova API code. This works well because the V2 and V3 APIs in
> many areas are very closely related anyway - so emulation is
> straightforward.
>
> However there is another alternative (which I don't think is necessary
> for V2) and that is to have a more fuller fledged type proxy where
> translation is say done between receiving V2 requests and translating
> them to native V3 API requests. Responses are similarly translated but
> in reverse. Its the sort of direction that we tried to steer the GCE
> API folks in Icehouse, though I don't know what they ended up doing -
> IIRC I think they said it would be possible.
>
> Longer term I suspect its something we should consider if we could do
> something like that for the EC2 API and then be able to rip out the
> ec2 API specific code from the nova API part of tree. The messiness of
> any UUID or state map translation perhaps could then be handled in a
> very isolated manner from the core Nova code (though I won't pretend to
> understand the specifics of what is required here). I guess the
> critical question will be if the emulation of the EC2 API is good
> enough, but as Sean points out - there are lots of existing issues
> already so it may end up not perfect, but still much better than what we
> have now.
>
> Chris
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev