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

Feodor Tersin ftersin at cloudscaling.com
Thu Apr 9 15:01:53 UTC 2015


Hi.

As you can see adjusted Tempest (https://review.openstack.org/#/c/171222/)
runs well against both Nova EC2 and ec2api (
https://review.openstack.org/#/c/172059).


On Tue, Apr 7, 2015 at 5:50 PM, Feodor Tersin <ftersin at cloudscaling.com>
wrote:

> 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/20150409/c9b45c06/attachment.html>


More information about the OpenStack-dev mailing list