The createBackup API is by default an admin-or-owner API, so it
should live in server-actions rather than server-admin-actions.
Change-Id: Ifdc08a1df39f30944d45e2001d590b34a963d062
Closes-Bug: #1679314
The following APIs which are considered as proxies of Neutron networking
API, are deprecated and will result in a 404 error response in new
Microversion:
POST /servers/{server_uuid}/action
{
"addFixedIp": {...}
}
POST /servers/{server_uuid}/action
{
"removeFixedIp": {...}
}
POST /servers/{server_uuid}/action
{
"addFloatingIp": {...}
}
POST /servers/{server_uuid}/action
{
"removeFloatingIp": {...}
And the nova-network specific API for query server's interfaces is
deprecated also:
GET /servers/{server_uuid}/os-virtual-interfaces
Partial implement blueprint deprecate-multinic-proxy-api
Change-Id: I1848db384a825d3b166f113b30ebad92113af8e5
The result of this method should be stable in database order, but since
we depend on it for some pagination, this patch sorts the results by
the most efficient thing we have to be sure.
Related to blueprint cells-aware-api
Change-Id: I81fb8a2a342ad54adc386c02a5fe4a90800fcbb0
Right now, the compute node is responsible for validating that the scheduler
honored the affinity policy of a server group. It does this by listing all
the instances in a server group and validating that affinity or anti-affinity
was kept true. With cellsv2, this check requires an upcall to the API
database as server groups are stored there. This violates our goal of not
allowing any upcalls to be congruent with known restrictions that actual
cells(v1) deployers require.
This adds a workaround flag, disabled by default, which defeats this check
in the compute node. For smaller deployments, isolation of the cell and api
services is not as big of a deal, so by default, this check will continue
to work as it does today. Larger deployments which care more about the
isolation than they do the absolute affinity guarantees can enable this
workaround to avoid the upcall check. A user can still detect a violation of
their affinity request by examining the obscured host identifier.
Longer-term, this problem goes away when we're doing claims in the scheduler
and placement has a notion of affinity that it can enforce early in the
boot process, eliminating the race and the need for this check entirely.
Related to blueprint cells-aware-api
Change-Id: I22e1a0736a269d89b55b71c2413fa763d5f1fd0c
This teaches the server groups api to query all of the cells that have
an instance claiming to be a member of the group. Instead of polling all
cells, this collects the subset of cells that actually have members,
according to our InstanceMapping data, and then checks for the deleted-ness
in the actual cell database.
This augments the tests to have one instance in each cell, plus an instance
that is not yet scheduled in any cell to give us coverage of all the
possibilities.
This replaces the previously-flawed and now reverted change:
If571f9e7c9d0ef6265a249ff808d30a24ab462af
Change-Id: Idd2e35bc95ed98ebc0340ff62e109e23c8adcb21
This same test has existed in os-brick for a long time:
I092a56e52bcea6adb6cb018cd059e6126a1dc07d
And since _get_target_portals_from_iscsiadm_output has been
changed in os-brick master to return a tuple instead of a
list, this test is actually blocking us from being able to
use os-brick 1.12.0.
This change just removes it since it's no longer needed in nova.
Change-Id: I82c31cc3b2ea3869ec37ff6add53abaec7a8591e
Closes-Bug: #1672670
This was originally added in change
I60abcd4f27dc877c4e420071be77c9fdb697ad99 because we still
created the BDMs in the API, and we did it based on the
build_request.block_device_mapping set in the _provision_instances
method.
We had to workaround the fact that BuildRequest.create()
would serialize the BDMs to store them in the DB, and then
deserialize them to set them on the BuildRequest object field.
As a result, the BuildRequest.block_device_mapping field was
orphaned (it lost it's internal RequestContext). So later on
when creating the BDMs from BuildRequest.block_device_mapping,
the update_or_create() remotable call would fail since the
object didn't have a context set. To workaround that we made a
clone of the BlockDeviceMappingList when creating the BuildRequest
and then set the original "dirty" list on the BuildRequest object
which was used later to create the BDMs.
In change I8742071b55f018f864f5a382de20075a5b444a79 we stopped
creating the BDMs in the API service and started created them
in the conductor service when calling schedule_and_build_instances.
And the block_device_mapping list passed to that conductor
method is the same one that we hacked into the BuildRequest object
in the earlier change (for the same reason really).
So at this point, we no longer need this confusing workaround and
can remove it.
Change-Id: I88e4d5cf38ee9ab4be9b8d7ae48bf273478fe3ef
The compute manager should be virt-driver agnostic for the
most part. This reference to errors in post-live migration
for QEMU predates gerrit and goes back to a diablo commit
with no further explanation of what's going on with this
change, but it looks like it's what added live migration
way back when:
1518e66d0c
It doesn't even make sense now, so remove it.
Change-Id: I144711f9e000c7e723f3b4e3dce56e3e922cf6e4
We have to continue scrubbing our documentation for anything
that generically refers to 'cells' since older documentation is
referring to cells v1, and we don't want people to confuse that
with cells v2. This simply provides a warning that cells v1 is
not recommended for new deployments and if you were looking for
help with cells v2 commands, we need to redirect you.
Change-Id: I3bd0332607bff169b5f496d17e4fc7d372ea991b
As of change If1e03c9343b8cc9c34bd51c2b4d25acdb21131ff, using
"nova hypervisor-list" before compute hosts are mapped to a cell
will result in an empty list.
Our cells v2 install steps mention using 'nova hypervisor-list' after
creating a cell and starting compute services to tell when to run
the discover_hosts command, but now hypervisor-list won't work until
you've run discover_hosts, so it's a catch-22.
This change adds a release note to let people writing deployment tools
to know about the change in behavior and also updates the install steps
to use service-list instead of hypervisor-list, since service-list does
not require the compute host to be mapped to the cell first.
We are going to need to make a similar change in the OpenStack install
guide since that also mentions using 'nova hypervisor-list' before
discover_hosts.
Change-Id: If2baab40c2e2a3de20e561bba50688d615b002ef
Closes-Bug: #1682060
Add auto_disk_config field to InstancePayload based on
instance.auto_disk_config boolean value. If true, set it to
AUTO else MANUAL.
Implements: bp additional-notification-fields-for-searchlight
Change-Id: I18af99479562e2fe5e74e6e1252b804b074fee58
Tags field is added to the InstanceUpdatePayload based on the
tags field fo the related Instance object. Adding tags to instance.create
notification will be handled in the bp tag-instances-when-boot.
Implements: bp additional-notification-fields-for-searchlight
Change-Id: Ifad6487de200767fc16d035ad830c77bba49154a
This change set introduces PowerVMDriver implementations for power_on,
power_off, and reboot.
Change-Id: I39233602c3485d2a93dd59fadeacd7795c8ab9bc
Partially-Implements: blueprint powervm-nova-compute-driver
Notification payloads always reflect the data needed for every
supported API microversion so we can safely use the latest
API version in the notification sample tests. This helps the test
to use the new API features too.
Change-Id: I851bd2e7ef13a1efa4fed4176996d71f6e2de94a
Building on Ic45bb064f4315ea9e63698a7c0e541c5b0de5051, this change set
makes the spawn and destroy methods functional in a basic way. A
subsequent change will introduce TaskFlow framework.
The VMs still have no network or storage - those will be coming in
future change sets.
Change-Id: I85f740999b8d085e803a39c35cc1897c0fb063ad
Partially-Implements: blueprint powervm-nova-compute-driver
This patch deprecates os-hosts APIs including:
GET /os-hosts - list hosts
GET /os-hosts/{host_name} - show host details
PUT /os-hosts/{host_name} - update host status
GET /os-hosts/{host_name}/reboot - reboot host
GET /os-hosts/{host_name}/shutdown - shutdown host
GET /os-hosts/{host_name}/startup - start host
Much of the ``os-hosts`` API is duplicated with the ``os-services`` and
``os-hypervisors`` APIs. It's not a good idea to make nova have the
compute related API, so this patch deprecated them.
Implements blueprint deprecate-os-hosts
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: Ieb85653b85a1eff38a9fb0c9ff05e4cd39150ecc
Use the new Cinder V3 attachment delete method
during detach if the BDM has an attachment_id in it.
This will only be present in the BDM if/when the
new attachment_create API is called. Otherwise, we
revert to the old calls.
Edge cases are handled in separate patches.
Partially Implements: blueprint cinder-new-attach-apis
Co-Authored-By: Steve Noyes <steve.noyes@oracle.com>
Change-Id: I91b9a60268354ffbed86b1e7d173906cfd7b97bd
This test is failing intermittently because it's waiting for a real
timeout from BackOffLoopingCall which does an exponential backoff
each interval. Sometimes the test times out entirely and fails.
This changes the test to mock BackOffLoopingCall and raise the timeout
exception to simulate a timeout. The only thing not covered by this is
calling of the _wait_state() function, but that is covered by other
unit tests in the file.
Closes-Bug: #1683953
Change-Id: Ie3ff6b0020dca8a5f5292b327aa2491920e338ef
The os-pci API was never part of the v2.0 API and was added
to the v3 API, but when the v3 API turned into the v2.1 API
which is backward compatible with the v2.0 API, the os-pci
API was removed from v2.1. The original intent was to enable
it in a microversion but that never happened.
We should just delete this API since it has a number of issues
anyway:
1. It's not documented (which makes sense since it's not enabled).
2. The PciHypervisorController just takes the compute_nodes.pci_stats
dict and dumps it to json out of the REST API with no control over
the keys in the response. That means if we ever change the fields
in the PciDevicePool object, we implicitly introduce a backward
incompatible change in the REST API.
3. We don't want to be reporting host stats out of the API [1].
4. To make the os-hypervisors extension work in a multi-cell environment
we'd have to add uuids to the PciDevices model and change the API to
return and take in uuids to identify the devices for GET requests.
5. And last but not least, no one has asked for this in over two years.
As a result of removing this API we can also remove the join on the
pci_devices table when showing details about an instance or listing
instances, which were added years ago because of the PciServerController:
Id3c8a0b187e399ce2acecd4aaa37ac95e731d46c
Id3e60c3c56c2eb4209e8aca8a2c26881ca86b435
[1] https://docs.openstack.org/developer/nova/policies.html?#metrics-gathering
Closes-Bug: #1426241
Closes-Bug: #1673869
Change-Id: I9099744264eeec175672d10d04da69648dec1a9d
Currently, a validation error is thrown if we find any PCI device
records which have not populated the parent_addr column on a nova
upgrade. However, the only PCI records for which a parent_addr
makes sense for are those with a device type of 'type-VF' (ie. an
SRIOV virtual function). PCI records with a device type of 'type-PF'
or 'type-PCI' will not have a parent_addr. If any of those records
are present on upgrade, the validation will fail.
This change checks that the device type of the PCI record is
'type-VF' when making sure the parent_addr has been correctly
populated
Closes-Bug: #1680918
Change-Id: Ia7e773674a4976fc03deee3f08a6ddb45568ec11
Matt Riedemann