Nowadays a significant amount of our test code coverage comes from
functional tests rather than just from unit tests.
Currently, we run unit tests under [testenv:cover] via .stestr.conf
and this just adds a run of the functional tests without API samples or
notification samples or database-only tests, for the sake of brevity.
In local testing this increases our Coverage Report from 87% to 89%
overall. And for the particular file I'm interested in,
nova/limit/utils.py, it increases coverage from 66% to 73%.
I'm doing this as a base for a bug fix in nova/limit/utils.py in the
next patch and with this change, I see coverage increase to 90%.
Change-Id: Iec0a9e38f3641e973894748ab2a14d1bd838e904
Signed-off-by: melanie witt <melwittt@gmail.com>
None of the other controllers do this. Don't do it here either. This is
mostly a bulk rename, with the exception of the combination of the
'_action_resize' and '_resize' methods, which were unnecessarily
separated, and the move of the 'delete' method to be next to the
'_delete' inner method.
Change-Id: I87381c6721e7a040c82f8124523116a1d4e2c684
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
All APIs except the root version APIs now use strict query string
parsing. A test is added to ensure same.
A couple of tests need to be updated since they were using the wrong
path: while the path is ignored when calling the controllers directly,
the query strings are not.
Change-Id: I6dcb5b8f1f865df8f6b17cd7f0d730c3bdff241e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Live migration of TPM instances is enabled only when the entire cloud
has been upgraded.
Related to blueprint vtpm-live-migration
Change-Id: I718d8ad48b82336562a880467c3c7b12b1fb3512
Signed-off-by: melanie witt <melwittt@gmail.com>
The name property of networks is optional in neutron. When a server is
attached to a network without name, the key can be empty.
Closes-Bug: #2142767
Change-Id: I31a82bb1574fab6ac03722571ff96443d7a3a51f
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
Adding more tests for graceful shutdown:
- shutdown the destination compute and see how live and cold migration
progress
- start build instance and ocne comoute start building instance then
shutdown the comoute service and see if build instance finish or not.
- revert resize server
Partial implement blueprint nova-services-graceful-shutdown-part1
Change-Id: I57132fb7b7fa614dfc138508581ff5a67aaed906
Signed-off-by: Ghanshyam Maan <gmaan.os14@gmail.com>
During graceful shutdown, compute service keep a 2nd RPC
server active which can be used to finish the in-progress
operations. Like live migration, resize and cold migrations
also perform RPC call among source and destination compute.
For those operation also, we can use 2nd RPC server and make
sure they will be completed during graceful shutdown.
A quick overview of what all RPC methods are involved in the
resize/cold migration and what all will be using 2nd RPC server:
Resize/cold migration
- prep_resize: No, resize/migration is not started yet.
- resize_instance: Yes, here the resize/migration starts.
- finish_resize: Yes
- cross cell resize case:
- prep_snapshot_based_resize_at_dest: NO, this is initial check and
migration is not started
- prep_snapshot_based_resize_at_source: Yes, this start the migration
Confirm resize: NO
- confirm_resize: NO
- cross cell confirm resize case:
- confirm_snapshot_based_resize - NO
Revert resize:
- revert_resize - NO
- check_instance_shared_storage: YES. This is called from dest to source
so we need source to respond to it so that revert can continue.
- finish_revert_resize on source- YES, at this stage, revert resize is
in progress and abandoning it here can lead migration to unreocverable
state.
- cross cell revert case:
- revert_snapshot_based_resize_at_dest: NO
- finish_revert_snapshot_based_resize_at_source: YES
Partial implement blueprint nova-services-graceful-shutdown-part1
Change-Id: If08b698d012a75b587144501d829403ec616f685
Signed-off-by: Ghanshyam Maan <gmaan.os14@gmail.com>
For graceful shutdown of compute service, it will have two RPC servers.
One RPC server is used for the new requests which will be stopped during
graceful shutdown and 2nd RPC server (listen on 'compute-alt' topic)
will be used to complete the in-progress operations.
We select the operations (case by case) and their RPC method to use
the 2nd PRC server so that they will not be interupted on shutdown
initiative and graceful shutdown time will keep 2nd RPC server active
for graceful_shutdown_timeout. A new method 'prepare_for_alt_rpcserver'
is added which will fallback to first RPC server if it detect the old
compute.
As this is upgrade impact, it bumps the compute/service version, adds
releasenotes for the same.
The list of operations who should use the 2nd RPC server will grow
evanutally and this commit moves the below operations to use the 2nd
RPC server:
* Live migration
- Live migration: It use 2nd RPC servers and will try to complete
the operation during shutdown.
- live_migration_force_complete does not need to use 2nd RPC server.
It is direct RPC request from API to compute and if that is
rejected during shutdown, it is fine and can be initiated again
once compute is up.
- live_migration_abort does not need to use 2nd RPC server. Ditto,
it is direct RPC request from API to compute. It cancel the queue
live migration but if migration is already started, then driver
cancel the migration. If it is rejected during shutdown because of
RPC is stopped, it is fine and can be initiated again.
* server external event
* Get server console
As graceful shutdown cannot be tested in tempest, this adds a new job
to test it. Currently it test the live migration operation which can
be extended to other operations who will use 2nd RPC server.
Partial implement blueprint nova-services-graceful-shutdown-part1
Change-Id: I4de3afbcfaefbed909a29a831ac18060c4a73246
Signed-off-by: Ghanshyam Maan <gmaan.os14@gmail.com>
Unlike the check for extra specs, the check for whether to include a
description field or not is driven entirely by API version rather than
API version and policy. We can therefore move the checks inside the
functions that generate the response rather than duplicating them
elsewhere.
Change-Id: I86aa4e1c62a0b0e6fa4d27e559d3197fb73851ba
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Ahead of adding additional tests. We do the following:
* Move the controller to an instance attribute rather than a class
attribute
* Modify tests so they all call controller methods directly rather than
setting up a fake router (this is the cause of the largest changes)
* Remove unnecessary aliasing of exceptions
* Remove unnecessary setUp arguments
* Split a test into multiple tests
* Standardize test class names
Change-Id: I2cac4cc79288f7b3bacc4a63a1d36d4cf12013d7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
So that we can use them for API DB methods, which are found in
nova.objects instead of nova.db.
Change-Id: Ifb15ee90ac6a6400b7268ed80f727080e98c4cdf
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
A follow-up for Ia178c1314f99c719827e3eb78735d1019852a273 and
I0e42de5074dcf699886b20dfd43306683e381ee2. 'adminPass' is only
(optionally) returned in server create and rebuild responses, not in
server show or update responses.
Change-Id: I2c4ce7a2b1063d71561d6af95a58a36b39356879
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Zuul