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
<alev...@cloudscaling.com <mailto:alev...@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 <mi...@stillhq.com <mailto: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
        <mailto:OpenStack-dev@lists.openstack.org>
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto: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



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to