This patch refactors the sample files of service-create, service-delete
and service-update notifications to use a common ServiceStatusPayload
sample data.
This patch addresses the problem which lead the revert of the commit
I708ce5423806d2913e77abbe338aec970a5009dc.
Change-Id: I2f619089ae88d05207bb3432c63546a298f0bf15
This reverts commit 39f9ef719e.
The reverted change made the service.update notification sample tests
failing consistently on master. The CI did not catch this problem as
the functional test does not run for changes that only touches
nova/docs. This is a quick fix to unblock the gate and fix the
functional job defintion in a separate patch.
Change-Id: Idabbf70ae46f36be8343c0a00d812cbebf7f7670
Closes-Bug: #1742935
This patch refactors the sample files of service-create, service-delete
and service-update notifications to use a common ServiceStatusPayload
sample data.
Change-Id: I708ce5423806d2913e77abbe338aec970a5009dc
We need to do this so we can have a migration uuid at the time we
call to scheduler to allocate for the new host. This just does the
plumbing through the RPC layers. The compute-side code can already
tolerate a migration having been already created for things like
live migration, so we just have to plumb it through.
Related to blueprint migration-allocations
Change-Id: I6bc6d28655368084f08fed9c4f56a285b7063338
Because we need to allow for a smooth upgrade from Ocata to
Pike, we need Pike compute hosts to be tolerant of the bad accounting
assumptions that Ocata compute hosts were making. If a user migrates an
instance from an Ocata compute host to a Pike compute host, the Ocata
compute host will continue essentially re-setting the instance
allocation to be an allocation against only the source Ocata host
(during the migration operation). We need to have the Pike destination
compute host recognize when its in a mixed Ocata/Pike environment and
tolerate this incorrect "healing" that the Ocata source host will do.
To tolerate this, the Pike destination compute host must continue to
behave like an Ocata compute host until all compute hosts are upgraded
to Pike or beyond.
Note that this adds service version caching for the compute service.
We were already doing the lookup for the RPC pin and caching that,
so this is not much of a change. Also note that we weren't clearing
this caching in tests, so any test that ran code that cached the
service version would affect later ones. This clears it as part of the
base test setup too.
Co-Authored-By: Jay Pipes <jaypipes@gmail.com>
Change-Id: Ia93168b1560267178059284186fb2b7096c7e81f
This adds the support for new style volume attachments
to the swap volume operation.
If the existing volume attachment (old_volume) was created
using the new flow, it will have attachment_id set. Based
on that the API will create a new volume attachment for the
volume being swapped to and then pass that attachment to the
compute over RPC. Note that we do not yet create new-style
volume attachments so this is all no-op code for now. And
when we do start creating new-style volume attachments, that
will only be allowed when Cinder is new enough (3.27 microversion)
and all compute services are upgraded, so we don't perform
any nova-compute service version checks here.
Once on the compute, we key off the new_attachment_id being
passed from the API to tell if we should use the old or new
style calls to Cinder. For example, initialize_connection and
terminate_connection are replaced with attachment_update and
attachment_delete.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Co-Authored-By: John Griffith <john.griffith8@gmail.com>
Depends-On: I23391300468cc5e2f45a12d5ad8617ab48c21e6a
Partially Implements: blueprint cinder-new-attach-apis
Change-Id: I4b8bd01f1ffe2640fe7313213bf853d2e1bef9dd
This patch adds support to the compute manager and Neutron API for
tagged attach for network interfaces.
Change-Id: I3ca96e6d791d609db8bf4368a3c71f880de8e7ad
Implements: blueprint virt-device-tagged-attach-detach
This patch adds support to the compute manager and API for tagged
attachment of block devices.
Change-Id: I1f25f8098a495c49e7021eb92b2cd5f048ced484
Implements: blueprint virt-device-tagged-attach-detach
New objects are children of NovaObject class. Such parent
will give us a good control of objects versioning. Also it
will force contributors to dump objects version in case of
any changes. These objects will be used to transmit data
via RPC. Old objects were used only for storing data.
During RPC transmission they are transform into dictionaries.
It is not right approach because we will have some problems
in case of adding new diagnostics fields.
Version of compute RPC was bumped.
Also some changes were made in libvirt driver method
get_instance_diagnostics(). These changes were made to fill
new fields of 'Diagnostics' object.
Implementation of method get_instance_diagnostics()
for other virt drivers will be changed in future patches.
blueprint: restore-vm-diagnostics
Change-Id: I5e2d116df045f803c654f7810b939b5fc859cfbf
Now that the services table has a uuid field and we'll be exposing
that out of the REST API, we should include the uuid in the
service.update notification payload.
Part of blueprint service-hyper-uuid-in-api
Change-Id: I8c400086a8dce9317a39f7e65c8d098d93af335d
Due to the not strict handling of uninitialized fields during
notification payload population it is possible that the emitted
notification missing some of the fields defined in the schema.
There are two problematic cases:
1) no load tirggered for lazy loaded fields. If the field was not
loaded it is not added to the payload.
2) uninitialized, not lazy loadable fields are not added to the
payload.
This patch makes sure that lazy load is triggered. If the field is
not lazy loadable and also not initialized then related payload
field will be set to None. If the payload field is not nullable
the code will fail to make sure that the inconsistency is detected.
The following changes cannot be split to different commits because
as soon as the generic schema population code is fixed every listed
notification starts behaving differently.
In some cases the availability_zone field of the Service object is left
unitialized by both the constructor and the obj_load_attr function this
caused that the availability_zone field of the service.update
notification was missing from the emitted notification payload.
The extra_specs field of the Flavor object is not lazy loadable and not
initialized in the Flavor destroy case. So the extra_specs field of the
FlavorPayload needed to be made nullable.
The projects field of the Flavor object is lazy loaded but when the
Flavor object is loaded as part of an Instance object Flavor is
orphaned and no lazy load is allowed on that Flavor object. In this
case the projects field of the FlavorPayload will be set to None to
signal that the information is not available. This also means that
the projects field of the FlavorPayload needed to be changed to
nullable.
The hosts and id fields of the Aggregate object is not initialized
during the create of the Aggregate before the aggregate.create.start
needs to be sent. Therefore these fields needs to be nullable.
Closes-Bug: #1653221
Change-Id: Ib122cd98ee0cc31938d5ff1d5c753053267a3bd4
This patch finishes to remove the 'check_attach' call from Nova
completely. As Cinder already performs the required checks as part
of the 'reserve_volume' (os-reserve) call it is unnecessary to check the
statemachine in Nova also and it can lead to race conditions.
The missing 'reserve_volume' call is added to the BFV flow. In case of
build failure the volume will be locked in 'attaching' state until the
instance in ERROR state is cleaned up.
We also check AZ for each volume attach operation which we haven't
done for unshelve. A release note is added to enable 'cross_az_attach'
in case the user does not care about AZ.
The compute service version had to be bumped as the old computes still
perform 'check_attach', which will fail when the API reserves the
volume and the volume state moves to 'attaching'. If the computes
are not new enough the old check will be called as opposed to
'reserve_volume'.
Closes-Bug: #1581230
Change-Id: I3a3caa4c566ecc132aa2699f8c7e5987bbcc863a
We need to signal that the compute is Ocata and since the placement is now
mandatory for Ocata, we want to hard-fail if the conf is not correct.
Depends-On: I573149b9415da2a8bb3951a4c4ce71c4c3e48c6f
Change-Id: I3919f652040f2be2641420dd469af01b268e65c9
This service version indicates that the successful delete of a
BuildRequest during instance deletion will cause nova-conductor to stop
a build when it notices that the BuildRequest is gone. This simplifies
the delete code for dealing with pre-scheduled instances.
Change-Id: I961d002cccd3e01a26cb5174e0804db7fc1f836d
This patch allows the network manager(s) to set virtual device tags if
they are present during allocation.
Implements: blueprint virt-device-role-tagging
Co-authored-by: Vladik Romanovsky <vromanso@redhat.com>
Co-authored-by: Dan Smith <dansmith@redhat.com>
Change-Id: I8367f740d6d4ebaeb81bc74c6a82a8faf5cd8308
Removes a longstanding TODO to update this method to handle instance
objects. The method is not actually used anywhere so there are no
upgrade concerns, but proper protocol is observed regardless.
Change-Id: Ieaf538fa2dc5c4a15574cc6aacac26abbac3b5a2
The REST API is going to be checking that all computes
in the deployment are running new enough code to support
network requests with the special 'auto' and 'none' values
for Get Me a Network, so we need to bump the service version
which can be used as the minimum version to check.
Part of blueprint get-me-a-network
Change-Id: Ia1af75422d5e1fd4535c1ed9703d855239282559
During force_live_migration operation there are 2
checks of migration status, one on api layer and one on
compute side, second one requires rpc request to be done
and also to query the db. This check could be removed as additional
one doesn't guarantee that live_migration is not already completed,
also is very small window between api and compute side.
Target compute host is now taken from migration object rather
then instance.host field, which allows to guarantee that nova will not
pause already migrated instance.
Change-Id: I51585302e898251e26cbf311aeac38a0ec329001
This does a live migration of compute node resource information from the
current location (in compute_nodes columns) to the new desired location
of records in the inventories table. It only does this if all control
services have been upgraded to a level that understands this.
Related to blueprint compute-node-inventory-newton
Change-Id: Ieda099d3f617713f09315b2b1e932a7c1d6f45c4
This reverts commit d411d60587.
The point of doc/*samples* is they are static files, not
dynamic. We shouldn't be doing substitution here, this
breaks all kinds of things, including the doc target.
Change-Id: Iaaf9fa0096ab62e6d3efbe018d8d4853a2ff8cda
Closes-Bug: #1553634
This way we avoid having to change the test template every time we bump
the version, it will be taken from the module.
Change-Id: I699b737e0e234f0649f6d207a648c60d74d9701e
This change adds a DELETE call on the server-migrations object to cancel
a running live migration of a specific instance.
TO perform the cancellation the virtualization driver needs to support
it, in case that the feature is not supported we return an error.
We allow a cancellation of a migration only if the migration is
running at the moment of the request and if the migration type is equal
to 'live-migration'.
In this change we implement this feature for the libvirt driver.
When the cancellation of a live migration succeeded we rollback the live
migration and we set the state of the Migration object equals to
'cancelled'.
The implementation of this change is based on the work done by the
implementation of the feature called 'force live migration':
https://review.openstack.org/245921
DocImpact
ApiImpact
Implements blueprint: abort-live-migration
Change-Id: I1ff861e54997a069894b542bd764ac3ef1b3dbb2
This change adds manual knob to force ongoing live migration to
complete. It is implemented as a new server-migrations API.
DocImpact
ApiImpact
Implements: blueprint pause-vm-during-live-migration
Change-Id: I034b4041414a797f65ede52db2963107f2ef7456
This makes us actually capable of sending migrate_data objects
over the wire and handles all the compatibility work to tolerate
older nodes without this support.
Note this also fixes a bug in the libvirt migration data
object where the serial console field should be nullable
(per existing code) but wasn't. Since this is the patch that
actually lets this object be sent over the wire, we can update
the definition and the hash without needing a version bump.
Related to blueprint objectify-live-migrate-data
Change-Id: I8ad7a91910e269c27bc74389a9d4d2c7388313d6
This patch adds infrastructure to store and verify json samples
about versioned notifications. Also it adds sample for the service.update
notification as that is the only existing versioned notification.
A new notification_sample_tests subtree added to the functional test
tree to verify that the emitted notifications match with the stored sample.
Partially-Implements: bp versioned-notification-api
Change-Id: I3a70b7b5d6d427611a9d2c1610e0d55aff88f0e8
Lajos Katona