Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/d002b1fe/attachment.html>