The os-testr 1.0.0 release had a couple of required config changes due
to it's internal usage of stestr. This commit fixes those by adding a
.stestr.conf (to remove a warning) sets the fixture env variables in
the tox.ini instead of being hidden in .testr.conf and removing the
quotes around posargs to make passing args to ostestr actually work.
Also to keep the expected dev experience stestr is used directly for
places where ostestr was called directly.
Change-Id: Ib0fbcb2e7710a6b8219c56ef2a4462c61ea498a9
If the MoveClaim during an evacuate fails we need to
remove the destination node allocation since the
ResourceTracker isn't going to do it.
This also fixes test_rebuild_server_exc which was faking
a rebuild failure by raising an error that would not
actually happen during a rebuild. ComputeResourcesUnavailable
only happens if a claim fails, and for a rebuild, which
is on the same host that the instance is already on, doesn't
involve a claim attempt.
Change-Id: I59ff47bf773c9831d0f44e1caf7877fe08c911c3
Closes-Bug: #1713786
If we actually make the MoveClaim but the evacuation fails
in the virt driver, the drop_move_claim via the MoveClaim.abort
will remove the destination node allocation. This adds a functional
test to show that works.
Change-Id: Ib58c487e97a041b8498746e8a276efffee239c56
Related-Bug: #1713786
This adds a functional recreate test for when the MoveClaim
fails on the destination node and the allocation on the
destination node is not cleaned up. This is because the
MoveClaim fails in it's constructor so it never exits the
Claim context manager to call the drop_move_claim which
would remove the destination node allocation.
Eventually we'll have to manually remove the destination
node allocation in the ComputeManager.rebuild_instance method.
Change-Id: I8900ace4436c4837beb8b4eb1e1d05905efc6dce
Related-Bug: #1713786
If a host is specified during an evacuate with the force=True
flag, conductor bypasses the scheduler. Since the scheduler
is what creates the "doubled up" allocation on the destination
node, and the scheduler is bypassed in the force case, we have
to create the allocations against the destination node in
conductor directly.
The unit tests cover the failure scenarios. The functional
test covers the happy path.
This is a short-term backportable fix. Long-term we'll likely
want to call the scheduler even in the 'force' scenario but pass
a flag to the scheduler to tell it to skip the filters but still
create the allocation on the destination node so we don't have
to duplicate that in conductor.
Change-Id: I6590f0eda4ec4996543ad40d8c2640b83fc3dd9d
Partial-Bug: #1713786
A subsequent change will add wait_for_legacy_notifications(). This
refactor achieves 2 things:
* Make it easier to return the notifications we were waiting for,
required in both current tests and subsequent legacy tests.
* Allow code re-use between fake legacy and versioned notifications.
It incidentally fixes a minor bug in
NotificationSampleTestBase._wait_for_notifications where we may wait for
up to double the specified timeout. It is also thread safe without
having to audit all code paths for potential eventlet context switch
points.
Change-Id: Ie4676eed0039c927b35af7573f0b57fd762adbaa
The instance.resize.error notification
is transformed to the versioned framework.
Change-Id: Ieb4ae4605fee8fbf58de4c5efb3c00083b4bd62c
Implements: bp versioned-notification-transformation-queens
This came up as a review comment in change
c19ebcbd58.
The tests being moved aren't related to move
operations, so they shouldn't be in the
ServerMovingTests class.
This moves them to separate classes and uses
distinct fake virt drivers to avoid monkey
patching the compute manager code in a functional
test.
Change-Id: I55edd2c6e4c752dbe675b6d51d71a047bf49597a
Fix AZ related API docs
While we have a big fat comment in the development docs explaining why it's so
terrible to use default AZ values for either booting an instance or setting
an aggregate AZ metadata, we still have confusing API docs that provide the
wrong name for the AZ...
Fixing that and trying to explain the problem within the docs, too.
This reverts commit 92ca21abd6.
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Change-Id: Ie4bfe32bbef0f8060bfc0ad4190f262d4a8bd3b2
Since nova-network is deprecated, networking is controlled by neutron.
This plugin here was used by nove-network and will confuse operators.
I tested on my own environment, and it seems safe to remove.
Change-Id: I1b64ea1f5906b0c4dd1d5e311095cfe41e884ff7
This reverts commit 71a7eda44b.
This is breaking the gate due to the change in the az name.
Change-Id: Idd7d1aab113f3d4aba8b1deb6e5dc3871a75aa29
Closes-Bug: #1716247
This fixes the two points in the note at the top of the
flavors page:
1. The policy rule in the first bullet was old so it's updated.
2. As of Ifa4e9cdfbbac1a1d4bf28679b24a17b13f637ddd in Pike,
Horizon no longer allows you to 'edit' a flavor by default.
Rather than try to explain historical bad behavior and the
new default behavior in the Dashboard, the second bullet is
simply removed.
Closes-Bug: #1715995
Change-Id: I372bf1e159d1db32461f843bd94c453d2e7df8d2
While we have a big fat comment in the development docs explaining why it's so
terrible to use default AZ values for either booting an instance or setting
an aggregate AZ metadata, we still have confusing API docs that provide the
wrong name for the AZ...
Fixing that and trying to explain the problem within the docs, too.
Change-Id: I811d0f219142ca435b2b206e9b11ccd5ac611997
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
In the unit test tox jobs we run the whole test suite first and after
that exits successfully we also run the osprofiler tests while setting
an osprofiler env variable to enable osprofiler. However the regex isn't
being set properly in ostestr, you set the selection regex with the
--regex flag. [1] This only works by chance because ostestr will pass
any unrecognized args to the subprocess used to run testr internally,
and testr leverages that as a regex. But in the latest os-testr release
it doesn't subprocess internally anymore and this doesn't work. This
commit fixes things to properly set the regex in ostestr so it works in
both old and new versions.
The order of the test runs is also switched because we capture the last
test run's subunit for openstack-health and other analysis, so we want
to full test run to be used for this.
[1] https://docs.openstack.org/os-testr/latest/user/ostestr.html#test-selection
Change-Id: I890505d65ca6043ddbdcc5895f2620391b505756
The keypair.delete.start and keypair.delete.end notifications
has been transformed to the versioned notification framework.
Change-Id: I48f28a56f9232faf52f458588500a9d77eb6b679
Implements: bp versioned-notification-transformation-queens
A nice simple example of how to move things to privsep (and the new set
of helpers). In a few of these cases I think a more complicated re-write
is actually required, but I've put TODOs there are will do those in a
followup patch.
Change-Id: Ibb6ef001e3f2add459b0e37dfbd9f51c9eff2eb7
The block_migrate_cinder_iscsi config option in Tempest says
the libvirt driver doesn't support live migration with an attached
volume because of bug 1398999 where volumes live on a network share
like RBD. However, I8fcc3ef3cb5d9fd3a95067929c496fdb5976fd41 in
nova says that this is possible with libvirt >= 1.2.17. Since we are
using libvirt 2.5.0 from the Ubuntu Cloud Archive on Xenial nodes
now, we should be able to enable this test.
Change-Id: I7d7a708b231070468616ae852d81d2f8b01ba568
Related-Bug: #1398999
We need this method for a similar fix in evacuate, so this
change pulls the method out of the LiveMigrationTask and moves
it into scheduler utils along with unit tests.
The only functional difference is that instead of raising
MigrationPreCheckError, it now raises NoValidHost, which for
live migration ends up being the same result when it's handled
in ComputeTaskManager.
Change-Id: Ie63a4798d420c39815e294843e02ab6473cfded2
Related-Bug: #1713786