The liberty, mitaka, and newton branches are closed so there is no
reason to scan for release notes dynamically. Use static content for
those pages to speed up the release notes build a little bit.
Change-Id: I983346c97df96fda988a2fefec89c3f0d6c14498
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Ironic nodes should all be using resource classes for scheduling by now,
which means reporting CPU/RAM/disk isn't useful. Report these as zero so
they cannot be scheduled.
Since we now require resource classes, raise an exception in
update_provider_tree for any nodes that don't have a resource class set
on the node.
Change-Id: If2b8c1a76d7dbabbac7bb359c9e572cfed510800
This reverts commit 8e6d5d404cf49e5b68b43c62e7f6d7db2771a1f4.
As detailed in the bug, this is overly racy, waiting for the event
potentially a long ways (and a couple RPC calls) away from where
the event will be triggered. The compute manager now has a generic
mechanism to do this which conflicts and replaces this functionality,
if enabled (default is off in Rocky, to be defaulted to on in Stein).
Conflicts:
nova/tests/unit/virt/libvirt/test_driver.py
nova/virt/libvirt/driver.py
Change-Id: Ibf2b5eeafd962e93ae4ab6290015d58c33024132
Closes-Bug: #1786346
Add a release note for blueprint
versioned-notification-transformation-rocky.
Change-Id: Ide95e93c2bcbfb8449fda9ee329409f71703ac01
Implements: bp versioned-notification-transformation-rocky
* nova-cert was removed in Pike: 2bcee77e3
* nova-network has been deprecated since newton: 7d5fc4868
* nova-consoleauth was deprecated in rocky: e91dad3ee
So start the timer on the related upgrade_levels options
so we can remove them.
Change-Id: Ied416335d36fe3324fb1c5c78353affe1332ba90
Now that we have this information, we can use it as a pre-filtering for
suitable hosts.
With this patch we complete the blueprint. As a result, documentation
and release notes are bundled in the patch and previously inactive tests
are now enabled.
Part of blueprint numa-aware-vswitches
Change-Id: Ide262733ffd7714fdc702b31c61bdd42dbf7acc3
This adds the "nova-manage placement sync_aggregates"
command which will compare nova host aggregates to
placement resource provider aggregates and add any
missing resource provider aggregates based on the nova
host aggregates.
At this time, it's only additive in that the command
does not remove resource provider aggregates if those
matching nodes are not found in nova host aggregates.
That likely needs to happen in a change that provides
an opt-in option for that behavior since it could be
destructive for externally-managed provider aggregates
for things like ironic nodes or shared storage pools.
Part of blueprint placement-mirror-host-aggregates
Change-Id: Iac67b6bf7e46fbac02b9d3cb59efc3c59b9e56c8
Add a method for libvirt driver to get cpu traits.
This is used for compute nodes to report cpu traits to Placement.
Change-Id: I9bd80adc244c64277d2d00e7d79c3002c8f9d57e
blueprint: report-cpu-features-as-traits
Drop support for the os-floating-ip-dns API which has been deprecated
since Newton:
Idca478c566f9a7b5b30a3172453ce7c66d9fd8f0
This API now returns a 410 response for all routes.
Unit tests are removed and the functional API sample tests are just
asserting the 410 response now.
The API sample docs are left intact since the API reference still builds
from those and can be considered more or less branchless, so people
looking at the API reference can apply it to older deployments of nova
before os-floating-ip-dns was removed.
The release note added for previous nova-network API removals is
amended to note this additional change.
Part of blueprint remove-nova-network
Change-Id: I0c4b586292814b8483226aee315f41cbefc86a1e
Drop support for the os-floating-ips-bulk API which has been deprecated
since Newton:
Idca478c566f9a7b5b30a3172453ce7c66d9fd8f0
This API now returns a 410 response for all routes.
Unit tests are removed and the functional API sample tests are just
asserting the 410 response now.
The API sample docs are left intact since the API reference still builds
from those and can be considered more or less branchless, so people
looking at the API reference can apply it to older deployments of nova
before os-floating-ips-bulk was removed.
The release note added for previous nova-network API removals is
amended to note this additional change.
Part of blueprint remove-nova-network
Change-Id: I89d081108b398d8efba9636279088c61349b21e6
Depends-On: https://review.openstack.org/582945
Right now, we still ask placement for a disk allocation covering
swap, ephemeral, and root disks for the instance even if the instance
is going to be volume-backed. This patch makes us not include the
root size in that calculation for placement, avoiding a false
failure because the volume size is counted against the compute's
available space.
To do this, we need another flag in request_spec to track the
BFV-ness of the instance. Right now, this patch just sets that on
new builds and the scheduler client assumes a lack of said flag
as "I don't know, so assume not-BFV" for compatibility. A
subsequent patch can calculate that flag for existing instances
so that we will be able to heal over time by migrating instances
or re-writing their allocations to reflect reality.
Partial-Bug: #1469179
Change-Id: I9c2111f7377df65c1fc3c72323f85483b3295989
This patch bumped API microversion to 2.65 to add support for
abort live migrations in ``queued`` and ``preparing`` status.
Part of blueprint abort-live-migration-in-queued-status
Change-Id: I4636a8d270ce01c1831bc951c4497ad472bc9aa8
Enable users to define the policy rules on server group policy
to meet more advanced policy requirement. This microversion
brings the following changes in server group APIs:
* Add ``policy`` and ``rules`` fields in the request of POST
``/os-server-groups``.
* The ``policy`` and ``rules`` fields will be
returned in response body of POST, GET ``/os-server-groups``
API and GET ``/os-server-groups/{server_group_id}`` API.
* The ``policies`` and ``metadata`` fields have been removed
from the response body of POST, GET ``/os-server-groups`` API
and GET ``/os-server-groups/{server_group_id}`` API.
Part of blueprint: complex-anti-affinity-policies
Change-Id: I6911e97bd7f8df92511e90518dba21c127e106a5
In this patch, the ServerGroupPayload is updated to include
the new ``policy`` field; the ``policies`` field is deprecated
for removal but still put into the notification payload for
backward compatibility.
Related to blueprint complex-anti-affinity-policies
Change-Id: Ie739ee8dec4685cd70e735ff83f7f30bc7e95a57
We can't easily add a blocker db sync migration to make
sure the migrate_instances_add_request_spec online data
migration has been run since we have to iterate both cells
(for instances) and the API DB (for request specs) and that's
not something we should do during a db sync call.
But we want to eventually drop the online data migration and
the accompanying compat code found in the api and conductor
services.
This adds a nova-status upgrade check for missing request specs
and fails if any existing non-deleted instances are found which
don't have a matching request spec.
Related to blueprint request-spec-use-by-compute
Change-Id: I1fb63765f0b0e8f35d6a66dccf9d12cc20e9c661
Address various minor issues from
https://review.openstack.org/#/c/565604/
Change-Id: I69df4c8d8c4b8813f78aeeb46f7b788d36238d35
Blueprint: add-consumer-generation
The instance action notifications contain the user id and the
project id of the owner of the instance. However an instance
action might be initiated by another user. It could be another
user from the same project or can be an admin from the admin project.
To be able to distinguish between the user who initiated the instance
action from the user owning the instance we need to add two new
fields to the instance action notifications, action_initiator_user
and action_initiator_project
Change-Id: I649d8a27baa8840bc1bb567fef027c749c663432
Closes-bug: #1744658
Blueprint: add-action-initiator-to-instance-action-notifications
This patch adds a microversion with a release note for allocation
candidates with nested resource provider trees.
From now on we support allocation candidates with nested resource
providers with the following features.
1) ``GET /allocation_candidates`` is aware of nested providers.
Namely, when provider trees are present, ``allocation_requests``
in the response of ``GET /allocation_candidates`` can include
allocations on combinations of multiple resource providers
in the same tree.
2) ``root_provider_uuid`` and ``parent_provider_uuid`` fields are
added to ``provider_summaries`` in the response of
``GET /allocation_candidates``.
Change-Id: I6cecb25c6c16cecc23d4008474d150b1f15f7d8a
Blueprint: nested-resource-providers-allocation-candidates
The way we store DB and MQ URLs in the API database causes issues for
some deployments (and deployment tools) which want to use per-host
credentials or remote hostnames. Since all the URLs loaded from the
database are the same on all systems, this becomes very difficult and
some have even resorted to using client-based aliasing underneath Nova
and just providing URLs that reference those aliases.
This makes our CellMapping object load the URLs out of the database,
and apply variable substitution from the CONF-resident base URLs
for any fields provided. Such functionality will let operators
define per-host credentials in [database]/connection, for example,
and have those applied to the database_connection URLs loaded from
CellMapping records.
Change-Id: Iab296c27bcd56162e2efca5fb232cae0aea1160e
Since libvirt 1.3.4, any RNG (Random Number Generator) device path (that
returns random numbers when read!) is accepted. However, the
recommended source of entropy is `/dev/urandom` (it is non-blocking; and
doesn't have the same limitations of `dev/random`, which is a legacy
interface).
Therefore, make `/dev/urandom` the default RNG for 'rng_dev_path' config
attribute; adjust the relevant tests. Also update the documention to
reflect this change.
Change-Id: Ia39402a045ffb1943463b5741655d84071613e8c
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
This drops support for the os-fixed-ips compute REST API which has been
deprecated since
Newton: I1a8a44530be29292561e90d6f7bd7ed512a88ee3
Now it returns 410 response. Unit tests are removed and the functional API
sample test is just asserting the 410 response now. The API sample docs are
left intact since the API reference still builds from those and can be
considered more or less branchless, so people looking at the API reference
can apply it to older deployments of nova before os-fixed-ips was removed.
Part of blueprint remove-nova-network
Change-Id: I61f758ff9285448d431b45f67c70286082b4ee90
