[openstack-dev] [nova] [qa] EC2 status and call for assistance

Christopher Yeoh cbkyeoh at gmail.com
Thu Apr 24 15:24:27 UTC 2014


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



More information about the OpenStack-dev mailing list