Now that we are using gitea the contents of our README.rst are
more prominently displayed. Starting it with a "Team and repository
tags" title is a bit confusing. This change makes it start with the
name of the project instead.
Change-Id: I8cefd1bd206520cd83d20807a07a3d55b8ce4d86
Both 'ServersTestBase' and 'InstanceHelperMixin' provide implementations
of '_wait_for_state_change' but they behave differently. The former
waits for an instance to transition *from* the provided state, while the
latter, somewhat more sanely, waits for the transition *to* the provided
state. Switch to using the latter everywhere and make the necessary
changes. Due to class hierarchies, we end up with two nearly identical
implementations but these will be merged in a future change.
Change-Id: I80cdc0a33ec27b1389130c22f9c3a8ff69f6b1a0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
It's Ussuri. We can *finally* stop testing Python 2 [1]. Time to party.
We don't attempt any cleanup but simply stop testing with Python 2,
indicate that we only support Python 3 via 'setup.cfg' and remove any
Python 2 only dependencies. Our 'tox.ini' is modified such that
'functional' now runs with 'python3', whatever that may point to, though
the gate will only use a versioned variant (currently
'functional-py36').
This should free up a significant amount of resources from the gate and
let us start using Python 3 idioms in our code. Win-win.
[1] https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html#python2-deprecation-timeline
Change-Id: Ie1a0cbd82a617dbcc15729647218ac3e9cd0e5a9
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This addresses a NOTE/TODO from change
I3cf6eb4654663865d9258c38f05cd05974ffcf9d where the NeutronFixture is
storing "admin-ness" from the last get_client call and using it to
control the behavior of the list_ports method.
This adds a wrapper class that represents a Neutron client object and
stores a reference to a NeutronFixture in order to track admin-ness for
separate get_client calls.
While making this change, unused methods:
fake_get_instance_security_group_bindings and _get_first_id_match were
noticed in NeutronFixture, so they are removed.
Change-Id: I7aa05e857599db820d0fc4daeb730f2a40b3291c
We want 'ServerBase' to inherit from 'InstanceHelperMixin'. They both
have implementations of a "wait until server is deleted" function. The
'ServerBase' implementation is called '_wait_for_deletion' and takes a
'server_id', while the 'InstanceHelperMixin' implementation is called
'_wait_until_deleted' and takes a full server JSON-y dict. A later
change, I0c56841d098d3e9d72db65be3143f3c893f0b6ba, will rework the
'ServersTestBase' version to bring it inline with 'InstanceHelperMixin'
version. However, 'ServerBase._delete_server' currently calls a
'_wait_for_deletion' function and passes it a 'server_id'. As such,
'_delete_server' itself is only passed a server_id. After the future
change, this 'server_id' will no longer be enough as '_delete_server'
will need to call the newly merged '_wait_until_deleted' that takes a
full server JSON-y dict, so '_delete_server' itself needs to receive a
full server JSON-y dict.
Do this work now to simplify the future patch.
Change-Id: Iceafa5ff2b7abff7c6d974ba49036ef03fb1c85f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This change simply extracts and slightly reorders the existing rescue
documentation from the reboot reference page.
Closes-Bug: #1852609
Change-Id: I4ce8874aa3e879e89ab5c7c76162561acbdea5c4
We want the 'IntegratedHelper' class to use the 'InstanceMixin' mixin
class. This is currently not possible because the latter is defined
after the former. This patch moves the class definitions around,
allowing us to do this in a future change when we've unified the
behavior of some competing functions provided by either.
Change-Id: I475b18272a5791aaa501ec5da1818ba22d8ec1f2
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
If while evacuating an active or stopped server the rebuild
resource claim or group affinity policy check fails, the state
of the server has not actually changed but the vm_state is changed
to ERROR because of the _error_out_instance_on_exception context
manager.
This builds on Ie4f9177f4d54cbc7dbcf58bd107fd5f24c60d8bb by
wrapping the BuildAbortException in InstanceFaultRollback for the
claim/group policy failures so the vm_state remains unchanged.
Note that the overall instance action record will still be marked
as a failure since the BuildAbortException is re-raised and the
wrap_instance_event decorator will fail the action (this is how the
user can know the operation failed).
Change-Id: I07fa46690d8f7b846665bc59c5e361873154382b
Closes-Bug: #1784983
This builds on I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a
which made DELETE /os-services/{service_id} fail with a 409
response if the host has instances on it. This change checks
for in-progress migrations involving the nodes on the host,
either as the source or destination nodes, and returns a 409
error response if any are found.
Failling to do this can lead to orphaned resource providers
in placement and also failing to properly confirm or revert
a pending resize or cold migration.
A release note is included for the (justified) behavior
change in the API. A new microversion should not be required
for this since admins should not have to opt out of broken
behavior.
Change-Id: I70e06c607045a1c0842f13069e51fef438012a9c
Closes-Bug: #1852610
This builds on I644608b4e197ddea31c5f264adb492f2c8931f04 and
adds a revert resize test which deletes the source compute service
while the server is in VERIFY_RESIZE status and then reverts the
resize. The results are a bit different from the confirm scenario
because the confirm fails while the revert actually works which
is more dumb luck based on where the compute service drops the
move claim during the revert process (on the dest which still exists
rather than the source).
Change-Id: I2dcb1cb3e1f8ed469a4c5bf81ca5ca2fcf1fa73c
Related-Bug: #1852610
It is possible to delete a source compute service which has
pending migration-based allocations and servers in VERIFY_RESIZE
status. Doing so deletes the compute service and compute node
but orphans the source node resource provider along with its
resource allocations held by the migration record while there
is a pending resized server.
This adds a simple cold migrate test which deletes the source
compute service while the server is in VERIFY_RESIZE status and
then tries to confirm the resize which fails.
Change-Id: I644608b4e197ddea31c5f264adb492f2c8931f04
Related-Bug: #1852610
Two things here:
1. The API guide was missing the hyper-v driver which supports
the suspend operation. Rather than hard-code a list of supported
drivers in the doc, this change just links to the entry in the
feature support matrix.
2. The supported hypervisors mention in the API reference is removed
because the end user using the API should not need to know or care
what backend hypervisor on which their server is running. They can
either suspend or not, but we don't need to mention the supporting
drivers for that in the API reference.
Change-Id: Ib76779a8e34b2c68b0f4af190f71576180360d0f
Related-Bug: #1815403
Thierry Carrez