[openstack-dev] [nova][ec2-api] Need advice about running Tempest against stackforge/ec2-api
Andrey M. Pavlov
andrey-mp at yandex.ru
Mon Apr 6 17:56:33 UTC 2015
06.04.2015, 19:38, "Sean Dague" <sean at dague.net>:
> On 04/06/2015 12:13 PM, Andrey M. Pavlov wrote:
>> 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 -
>> And now we face two problems (that can also be found in tempest logs of this review -
>> For now I switched tempest gating job to non-voting until these problems are resolved in the following review -
>> 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.
Ok. I'll create review.
>> 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
EC2 API can start a working guest from one image(that has ramdisk/kernel properties)
And our functional tests have such tests. For example we have test that ssh-s into guest and checks correctness of userData.
But we use cirros image that has links to kernel/ramdisk.
Difference between running instance from image that has links to kernel/ramdisk (or image with ramdisk/kernel inside)
and running instance from three images - where image, kernel and ramdisk are placed separately.
>> 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,
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Sean Dague
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev