Hi Sean
On Mon, Apr 6, 2015 at 7:34 PM, Sean Dague <s...@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-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