test_create_key_pair_quota_limit is one of nova's slowest tests,
because it creates 11 cryptographic keypairs.
Similarly, test_create_key_pair is slow because it creates 7 keypairs.
Neither test actually cares that the keypairs are cryptographically
secure, so mock out the actual generation of the keypairs.
The function xrange() was renamed to range() in Python 3.
Use "from six.moves import range" to get xrange() on Python 2 and range() on
Python 3 as the name "range", and replace "xrange()" with "range()".
The import is omitted for small ranges (1024 items or less).
This patch was generated by the following tool (revision 0c1d096b3903)
with the "xrange" operation:
* Replace range(n) with list(range(n)) in a loop of
nova/virt/libvirt/driver.py which uses list.pop()
The syntax "raise a, b, c" and "raise a, b" are invalid in Python 3.
To be compatible with Python 2 and Python 3, this change:
* Replace "raise exc, exc, exc" with "six.reraise(*exc)"
* Replace "raise exc_type, exc_value, exc_tb" with
"six.reraise(exc_type, exc_value, exc_tb)"
* Replace "raise exc, msg" with "raise exc(msg)"
This patch was generated by the sixer tool version 0.2 with the "raise"
* Ignore changes on comments
to compare objects, that contains nested collections new method
assertJsonEqual was used. Its usage allows not to rely on constant
order of nested collections elements.
assertJsonEqual was used
Now that the Scheduler has RPC calls to receive updates from compute
whenever a compute node's instances change significantly, we need to
add calls to compute to send those updates.
We add a new CONF option 'scheduler_instance_sync_interval'. This
option is an integer representing the interval (in seconds) that the
compute node waits between sending a sync message to the Scheduler. It
defaults to 120 (2 minutes). Of course, if the CONF option
'scheduler_tracks_instance_changes' is False, the sync calls will not
be made. If an operator notices in the logs that out-of-sync
situations are not very common, this value can be increased to lower
the number of RPC messages being sent. Likewise, if sync issues turn
out to be a problem, this can be lowered to check more frequently.
Partially-Implements: blueprint isolate-scheduler-db
The DatabaseFixture was previously just ensuring that tests which used
it had a clean database when they started. It did not ensure there was
no working database around when it wasn't being used, so tests which
leaked into the database might pass even if they were listed as a
NoDBTest, because there was an in memory test db from a prior run.
This adds a cleanup path to the fixture which blows away the db at the
end of the test (which itself is tested). There were 46 tests which
failed when we got this isolation correct, and this changes all those
test classes containing those tests to require a db. Many of these
could have narrower fixes, but this returns us to an isolated state.
This patch changes, where it's posible, tests-package
to using test.NoDBTestCase saving test case running time.
Co-Authored-By: yuntongjin <firstname.lastname@example.org>
Convert the use of the incubated version of the log module
to the new oslo.log library.
Sync oslo-incubator modules to update their imports as well.
Co-Authored-By: Doug Hellmann <email@example.com>
Change I682a377d769312e8f37f874aa4548665b3b52ed3 made this test
inherit from NoDBTestCase. However, this test does access the db if
ec2utils.get_int_id_from_snapshot_uuid() can't return a value from its
memo cache. That is, it was only passing due to fortunate test
ordering which populated this cache in a previous test. If you ran the
test isolated, it failed.
This change mocks ec2utils.id_to_ec2_snap_id to return expected values
without touching the db.
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.
This commit includes:
- using oslo_utils instead of oslo.utils
- using oslo_serialization instead of oslo.serialization
- using oslo_db instead of oslo.db
- using oslo_i18n instead of oslo.i18n
- using oslo_middleware instead of oslo.middleware
- using oslo_config instead of oslo.config
- using oslo_messaging instead of "from oslo import messaging"
- using oslo_vmware instead of oslo.vmware
Commit 488fcb4ad3 added a helper
for getting the AZ for a instance. This patch makes use of that
This also removes the now unused get_availability_zone_by_host()
method from ec2utils and adds a reset_cache() call to the class
setup of CloudTestCase in test_cloud.py to reset the cache now
used between tests.
Since pylint testing has been removed, there is little need to
keep the source code annotations for it. If anyone wishes to
re-add pylint later, they'll have to audit all the 10's of
1000's of pylint warnings and decide which to skip. So removing
the ~20 existing annotations is no real burden.
The following replacements were done in tests to have
clearer messages in case of failure:
- assertTrue(a in b) with assertIn(a, b)
- assertTrue(a not in b) with assertNotIn(a, b)
- assertFalse(a in b) with assertNotIn(a, b)
The error message would now be like:
'abc' not in ['a', 'b', 'c']
'False is not True'.
The test doesn't hit the database at all so make it
As far as I can tell this is the last ec2 API unit test
class that isn't a trivial convert to NoDBTestCase, all
the rest require some mocking of the objects or DB API
layers to convert them to NoDBTestCase, which I plan to
work on in later patches.
There is a weird namespacing issue happening here where the
nova.network.neutronv2.api package is relying on nova.network.neutronv2.
This is backwards from standard design and results in strange sharing
patterns when trying to do clean up.
httplib.HTTPSConnection is known to not verify SSL certificates
in Python 2.x. This change replaces use of httplib.HTTPSConnection
with the requests module. It imports config settings related to SSL
verification: ssl.key_file, ssl.cert_file, and ssl.ca_file. It also
adds one config setting: keystone_ec2_insecure. By default, SSL
verification is on, but can be disabled by setting:
This patch is based on the keystone middleware ec2 token patch:
There are no checks in nova-network to see if a specified
floating IP pool exists or not before attempting to allocate
an IP address. If a pool does not exist, nova throws an
unrelated error - 'No more floating ips available'. The
following patch adds a check for the existence of the IP pool
and throws a FloatingIpPoolNotFound if it is not found.
The fixtures in nova/openstack/common will be removed as
they have been removed from oslo-incubator. We should use
the fixtures from oslotest.
Note that oslotest uses mox3 instead of mox and some of the
tests were failing as a result which have been fixed in this
review. Only the failing tests have been fixed, so you will
see some tests use a mix of mock and mox3 as a result.
Based on feedback from Nova core, all existing references
to 'import mox' have been switched over to mox3 as well.
While volume is still attaching/detaching, AWS reports 'attaching'/
'detaching' states in the volume attachment info and instance bdm.
But Nova EC2 reports None, 'attached', or 'detached' states.
This fix set 'attaching'/'detaching' states in output results when
it's possible and while corresponding process is still active.
As part of the split of functional and unit tests we need to isolate
the unit tests into a separate directory for having multiple test
targets in a sane way.
Part of bp:functional-tests-for-nova