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 <mi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
