[openstack-dev] [nova][ec2-api] Need advice about running Tempest against stackforge/ec2-api

Feodor Tersin ftersin at cloudscaling.com
Tue Apr 7 14:50:06 UTC 2015


Hi Sean


On Mon, Apr 6, 2015 at 7:34 PM, Sean Dague <sean at dague.net> wrote:

> On 04/06/2015 12:13 PM, Andrey M. Pavlov wrote:
> > Hi,
> >
> > We've got a couple of problems running original Tempest EC2 API test
> against new standalone stackforge/ec2-api project and
> > I wanted to ask for some advice about how to deal with it.
> >
> > Tempest now is running against our ec2-api after this review was closed -
> > https://review.openstack.org/#/c/170258/
> >
> > And now we face two problems (that can also be found in tempest logs of
> this review -
> > https://review.openstack.org/#/c/170668/)
> > For now I switched tempest gating job to non-voting until these problems
> are resolved in the following review -
> > https://review.openstack.org/#/c/170646/
> >
> > Problems are:
> > 1)
> tempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip
> > this test tries to allocate address and disassociate it without
> association.
> > Amazon allows to do it and does not throw error. But EC2 implementation
> in Nova throws error.
> > We have the same test in our own test suite against stackforge/ec2-api
> (but it's not merged yet) and I checked it against Amazon.
> > I suggest to remove this test from tempest as incompatible with Amazon.
> > Also it can be skipped but for me it has no sense.
>
> This seems fine as a removal.
>
> > 2)
> tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes
> > This test registers three images by their manifests, run instance with
> image/kernel/ramdisk parameters,
> > and ssh into this instance to check something.
> > This is not the only test that runs instance with such parameters but
> this is the only one
> > that ssh-s into such an instance.
> > This instance runs but test can't ssh into it and it fails. Because this
> instance doesn't have ramdisk and kernel.
> > It runs supplied with image property only. The VM comes up
> semi-functional and instance can't boot up as a result.
> > Problem is in the ec2-api/nova communication. Nova public API doesn't
> support kernel and ramdisk parameters during instance creation.
> >
> > Next I'll file a bug to ec2-api with this description.
>
> This seems problematic, because I think what you are saying is that the
> stackforge EC2 API can't start a working guest. This is the only one of
> the ec2 tests that actually validates the guest is running correctly IIRC.
>
> Is there an equivalent test that exists that you think would be better?
> I'm also not sure I understand where the breakdown is here in missing
> functionality.
>

I suggest to fix the test to fit both Nova EC2 and ec2api restrictions.
Ec2api ignores ari/aki parameters for RunInstances operation, but supports
registration of an ami image linked to ari and aki ones.
Nova EC2 ignores the links in image registrations, but supports ari/aki
parameters for RunInstances operation.
So we could set these parameters for both operations to pass this test
agains both Nova EC2 and ec2api.

I've propesed a change for this: https://review.openstack.org/#/c/171222/



> > In the long run we should discuss adding this feature to public API but
> for now we'd like to put Tempest
> > in our project back to voting state.
> > We've got several options about what to do for this and we need some
> help to pick one (or several):
> > 1) skip this test in tempest and switch tempest back to voting state in
> our project.
> > The problem is that this test is still also employed against nova's EC2
> so it'll get skipped there as well.
> > 2) Leave it as non-voting until extension is added to nova.
> > Great solution but it'll take way too long I understand.
> > 3) add special condition to skipping the test so that it's skipped only
> when employed against stackforge/ec2-api,
> > while still working against nova if it's possible at all and not too
> much hassle.
> >
> > Kind regards,
> > Andrey.
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150407/2ba721a9/attachment.html>


More information about the OpenStack-dev mailing list