The document doesn't follow previous pattern to guide use
in using nova user to execute command and lead to issue
Change-Id: I795706a8f78ab4154bd39ce6259901800b34890e
Closes-Bug: 1781573
If we're updating existing allocations for an instance due
to the project_id/user_id not matching the instance, we should
use the consumer_generation parameter, new in placement 1.28,
to ensure we don't overwrite the allocations while another
process is updating them.
As a result, the include_project_user kwarg to method
get_allocations_for_consumer is removed since nothing else
is using it now, and the minimum required version of placement
checked by nova-status is updated to 1.28.
Change-Id: I4d5f26061594fa9863c1110e6152069e44168cc3
Split up the evacuate instance documentation into two parts. One
for the existing single instance evacuation and a second new part
for the nova host-evacuate procedure.
Change-Id: Ibcdc2bc3f08e2fab23b9821feae0f489fb64a8f7
Closes-Bug: #1763039
The code to generate a support matrix has been pulled into a common
library. Using this instead of duplicating code in various projects that
need it.
Change-Id: If5c0bf2b0dcd7dbb7d316139ecb62a936fd15439
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Allocations created before microversion 1.8 didn't have project_id
/ user_id consumer information. In Rocky those will be migrated
to have consumer records, but using configurable sentinel values.
As part of heal_allocations, we can detect this and heal the
allocations using the instance.project_id/user_id information.
This is something we'd need if we ever use Placement allocation
information counting quotas.
Note that we should be using Placement API version 1.28 with
consumer_generation when updating the allocations, but since
people might backport this change the usage of consumer
generations is left for a follow up patch.
Related to blueprint add-consumer-generation
Change-Id: Idba40838b7b1d5389ab308f2ea40e28911aecffa
The docs currently name a past PTL by IRC nick -- update it to be
more generic so we don't have to update it every time the PTL
changes.
Change-Id: I31dbf0ee4f7650389e824c25c3aea7529d63eaa0
This just links to the osc-placement plugin docs
for managing required and forbidden traits in the
flavor extra specs docs.
Change-Id: I8549dc404a62a05d327a2c7a4813e7cc505d6b06
Bump the minimum version of oslo.config to 6.1.0, which adds proper
support for parsing Opt.help as rST [1]. This in turn allows us to
revert commit 75fc300901, which is a
temporary fix relying on deprecated features of Sphinx.
[1] https://review.openstack.org/#/c/553860/
Change-Id: I8f56bdce37cfc538348490052a24e463164c86a3
This change provides a small number of updates to the placement user and
contributor documentation to reflect some of the things that have
changed recently. This is by no means complete, but is an improvement
over what was there.
Partial-Bug: #1778227
Change-Id: Ia348cd3c99b1a5104e15595fdebc83e1ca582a98
Replace nova commands with openstack commands.
Add an example to create a private flavor.
Repopulate the "Modify a flavor" section.
Replace 'extra_spec' with 'extra_specs'.
Fix a wrong link.
Remove rxtx-factor in descriptions and command examples.
Change-Id: I14295dddc302a603a71f71ccb6fcc5745ca7826c
enhance doc including remove 'nova-api' daemon which is deprecated
to use wsgi instead, and added some operations for password
response.
Change-Id: I4cb7ac55683951aa5900699ba587da03c22fb0a1
When rescuing an instance having a vGPU, we were not using the vGPU.
There would then be a race condition during the rescue where the vGPU
could be passed to another instance.
Instead, we should just make sure the vGPU would also be in the rescued
instance.
Change-Id: I7150e15694bb149ae67da37b5e43b6ea7507fe82
Closes-bug: #1762688
This adds two things:
1. Mention the img_config_drive image property
which can be used to force a config drive.
2. Note that the config_drive_cdrom config option
is for hyper-v only.
Change-Id: Id9a16e07709a445814fb7a183bd12f7740722ced
File injection is disabled by default (see
[libvirt]/inject_partition) and deprecated
in the API since microversion 2.57. We
don't really want people relying on file
injection, so this removes it from the
config drive docs. While in here, also
replace the 'nova boot' command mention
with 'openstack server create' since that
is the command used through the examples.
Change-Id: I4521eca6f6cbd4f8cd6dad48ab1d40a1b136bf73
The xenapi_disable_agent config option was moved to
[xenserver]/disable_agent so this just updates the config
drive docs.
Change-Id: I6573e7c86d00e9174a5219397f676503c0e9b744
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
There were a few changes needed here:
1. There is no "API cell database", just the API
database, so this removes mentions of cells.
2. The VERSION argument was missing from the sync help.
3. The sync command does not create a database, it upgrades
the schema. Wording for that was borrowed from the
nova-manage db sync help.
4. Starting in Rocky, the api_db sync command also upgrades
the schema for the optional placement database if configured
so that's mentioned here as well.
Change-Id: Ibc49f93b8bd51d9a050acde5ef3dc8aad91321ca
Closes-Bug: #1778733
Add the discard flag to libvirt XML when supported by libvirt and qemu,
and when using file backed memory.
The discard flag causes qemu to discard allocated memory via calling
madvise with MADV_REMOVE when using file backed memory, to prevent
writing out dirty instance memory. This is a significant performance
improvement for shutting down instances that have recently written to
significant portions of their memory.
As qemu and libvirt do not guarantee the discard is run, this cannot be
used for security purposes.
Change-Id: Ia7cf4414feb335b3c2e863b4c8b4ff559b275c34
Implements: blueprint libvirt-file-backed-memory
File backed memory is enabled per Nova compute host. When enabled, host
will report 'file_backed_memory_capacity' for available memory.
When enabled, instances will create memory backing files in the
directory specified in libvirt's qemu.conf file 'memory_backing_dir'
config option.
This feature is not compatible with memory overcommit, and requires
'ram_allocation_ratio' to be set to 1.0
Change-Id: I676291ec0faa1dea0bd5050ef8e3426d171de4c6
Implements: blueprint libvirt-file-backed-memory
This adds a new policy rule which defaults to behave in a
backward compatible way, but will allow operators to enforce
that servers created with a zero disk flavor must also be
volume-backed servers.
Allowing users to upload their own images and create image-backed
servers on local disk with zero root disk size flavors can be
potentially hazardous if the size of the image is unexpectedly
large, since it can consume the local disk (or shared storage pool).
It should be noted that disabling the new policy rule will
result in a non-backward compatible API behavior change and no
microversion is being introduced for this because enforcement via
a new microversion would not close the security gap on any previous
microversions.
Related compute API reference and user documentation is updated
to mention the policy rule along with a release note since
this is tied to a security bug, which will be backported to stable
branches.
Change-Id: Id67e1285a0522474844de130c9263e11868f67fb
Closes-Bug: #1739646
Even though the feature is technically virt driver agnostic,
the plumbing happens through the virt drivers, so the feature
is only supported by certain virt drivers (libvirt only at
the time of this patch). So this adds a section to the feature
support matrix about the trusted certs validation feature.
Also updates the certificate validation user docs based on
the nova boot --trusted-image-certificate-id option name
in the dependent python-novaclient change.
Depends-On: https://review.openstack.org/500396/
Related to blueprint nova-validate-certificates
Change-Id: Ic5cb4a98c73cc404c7033cf183f25a97aba3c994
Zuul