Even if tempest leaked every server it created (which is definitely not happening) if the network allocates a /24 there should still be plenty of ips available. From the logs above tempest only allocated a total of 171 servers:
But the exception is a quota one, the default tenant quota for a fixed ips is definitely more than 2. (otherwise we'd have much larger issues) I'm pretty sure we set it to -1, but I'm not sure. Looking at the test class in question:
The the tenant for that class will only have 2 server create calls. One in setUpClass and one in this test. I have a hard time believing 2 fixed ips exceeded the quota limit. Looking at the tests running around the same time, starting at:
I don't see anything that should have accidentally changed the quota to be < 2. I guess there could be a more hidden cross interaction because there are a bunch of admin api tests running around the same time (the joys of a default alphabetical test order), but I don't see one yet.
Even if tempest leaked every server it created (which is definitely not happening) if the network allocates a /24 there should still be plenty of ips available. From the logs above tempest only allocated a total of 171 servers:
http:// logs.openstack. org/23/ 112523/ 1/check/ check-tempest- dsvm-postgres- full/acac6d9/ logs/qemu/
But the exception is a quota one, the default tenant quota for a fixed ips is definitely more than 2. (otherwise we'd have much larger issues) I'm pretty sure we set it to -1, but I'm not sure. Looking at the test class in question:
http:// git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ api/compute/ admin/test_ servers_ negative. py
The the tenant for that class will only have 2 server create calls. One in setUpClass and one in this test. I have a hard time believing 2 fixed ips exceeded the quota limit. Looking at the tests running around the same time, starting at:
http:// logs.openstack. org/23/ 112523/ 1/check/ check-tempest- dsvm-postgres- full/acac6d9/ console. html.gz# _2014-08- 07_09_42_ 03_634
which was the last test from a previous class on the same thread, until the same thing after the failed test:
http:// logs.openstack. org/23/ 112523/ 1/check/ check-tempest- dsvm-postgres- full/acac6d9/ console. html.gz# _2014-08- 07_09_42_ 27_778
I don't see anything that should have accidentally changed the quota to be < 2. I guess there could be a more hidden cross interaction because there are a bunch of admin api tests running around the same time (the joys of a default alphabetical test order), but I don't see one yet.