Open Stack

06.04.2015, 19:38, "Sean Dague" <sean at 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-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