Open Stack

On 4/25/2014 4:13 AM, Alexandre Levine wrote:
> Joe,
>
> In regard to your first question - yes we'll be going in this direction
> very soon. It's being discussed with Randy now.
> As for the second question - we'd love to participate in fixing it (in
> fact we've done it for OCS already) and probably maintaining it but I'm
> not sure what it takes and means to commit to this - we'll discuss it as
> well.
>
> Best regards,
>    Alex Levine
>
> 24.04.2014 23:33, Joe Gordon пишет:
>>
>>
>>
>> On Thu, Apr 24, 2014 at 10:10 AM, Alexandre Levine
>> <alevine at cloudscaling.com <mailto:alevine at cloudscaling.com>> wrote:
>>
>>     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.
>>
>>
>> Any plans to contribute this to the community?
>>
>>
>>     But anyways, I'm completely convinced that:
>>
>>     1. Any further improvements to EC2 layer should be done after its
>>     separation from nova.
>>
>>
>> So the fundamental problem we are having with Nova's EC2
>> implementation is that no one is maintaining it upstream.  If pulling
>> EC2 out of nova into its own repo solves this problem then wonderful.
>> But the status quo is untenable, Nova does not want to ship code that
>> we know to be broken, so we need folks interested in it to help fix it.
>>
>>     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 <tel:24.04.2014%2019>:24, Christopher Yeoh пишет:
>>
>>         On Thu, 24 Apr 2014 09:10:19 +1000
>>         Michael Still <mikal at stillhq.com <mailto: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
>>         <mailto:OpenStack-dev at lists.openstack.org>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>     _______________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.org
>>     <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

It looks like a fork was created in stackforge last June and development 
has been active since. [1]

Is there a roadmap then to removing the ec2 API from nova's tree since 
it looks like the effort in maintaining and improving this code is now 
out of tree.

[1] https://github.com/stackforge/ec2-api

-- 

Thanks,

Matt Riedemann