06.04.2015, 19:38, "Sean Dague" <s...@dague.net>: > 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.
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 > functionality. 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, >> Andrey. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
