Adds a section in the admin guide with the config options related to
down cells.
Related to blueprint handling-down-cell
Change-Id: I6a6cc71e83896aaccd5dd98bc2ea024d6f22d528
This patch adds the documentation around the work regarding
handling down cells that was introduced in v2.69.
Related to blueprint handling-down-cell
Change-Id: I78ed924a802307a992ff90e61ae7ff07c2cc39d1
Remove the 'os_compute_api:os-flavor-manage' policy.
The 'os_compute_api:os-flavor-manage' policy has been deprecated
since 16.0.0 Pike.
The policy has been replaced with the following policies.
- os_compute_api:os-flavor-manage:create
- os_compute_api:os-flavor-manage:delete
Change-Id: I856498dfcebfa330598a22dd7c660bd6f158351b
This change is an update to the nova reference documentation to reflect
changes to the ComputeDriver.update_provider_tree method in nova drivers.
Change-Id: Ifae98d888069477748ade7ef5e0a5cde5c88ffc2
Closes-Bug: #1800657
In the contributor documentation, don't reference specific
distribution versions since they'll inevitably get out of date, and
these instructions are valid for all releases in the last 5 years at
least, and are not likely to change any time soon.
Change-Id: I7e7391a8850cf8a9dda763d9b85242fbbbb42af7
This is a follow up to change I0f206d9db70465d8ce6b1404f546f3e00eeb6e23
where we changed the docs from using "nova flavor-update" to
"openstack flavor set --description" but unlike nova CLI which
negotiates the highest available microversion by default, OSC does not
and defaults to 2.1 which won't work when trying to set a flavor
description. This change adds the --os-compute-api-version option
to the command line example to make that command work.
Change-Id: I7eacc30b4cf3a5ef89f90ec599f21eaa12bf2a10
In a fairly hack and slash fashion, remove the installation of placement
from the nova install docs. Placement will have its own installation
docs.
Configuring access to placement from the controller and compute nodes is
still described.
The depends-on is to the patch that provides placement install docs.
The output of 'nova-status upgrade check' is updated to reflect the
current state of the output of that command; this means it now
includes a fair bit more than checking cells v2 and the existence
of the placement API.
Depends-On: https://review.openstack.org/#/c/628220/
Change-Id: I9e082a9c6d4b6369f1ec6c17bbd3ccc417a5e97b
Remove links to internal placement documentation. Instead indicate
that placement is required by nova, and point elsewhere.
The depends-on adds placement install docs to the placement repo.
Depends-On: https://review.openstack.org/628220
Change-Id: I9f0d52e7b46b270363946211cf6dc0c338981cb2
Convert ``option`` to the shiny :oslo.config:option:`section.option`
format in admin/configuration/hypervisore-kvm.
Recognizing this could be done to a lot more files; I just happened to
be looking at this one today.
Change-Id: If1b02ce99152ffd00d4f461dc4539606db1bb13b
The first section in the doc mentions the properties of
a flavor but didn't mention description which was added
in 2.55 so this adds it.
Change-Id: Id73a2665e7fa914e00dc60a085a7cd9f47655a73
- This change updates the admin flavor docs
to reflect the use of osc to update flavor
descriptions
- This change documents that modifcations to
flavor extra_specs are not reflected in an
instance's embedded flavor.
Change-Id: I0f206d9db70465d8ce6b1404f546f3e00eeb6e23
The dependent tempest change enables the volume multiattach
tests in the tempest-full and tempest-slow jobs, on which
nova already gates, which allows us to drop the special
nova-multiattach job which is mostly redundant test coverage
of the other tempest.api.compute.* tests, and allows us to
run one fewer job on nova/cinder/tempest changes in Stein.
The docs are updated to reflect the source of the testing
now.
Also depends on cinder dropping its usage of the nova-multiattach
job before we can drop the job definition from nova.
Depends-On: https://review.openstack.org/606978
Depends-On: https://review.openstack.org/606985
Change-Id: I744afa1df9a6ed8e0eba4310b20c33755ce1ba88
This took me a good hour to suss and while there were a couple of Google
hits for it, the top suggestion was to use TCP (rather than SSH) and
disable all security, which is rarely good advice.
Paste an sample error and link to the doc where you can find advice of
resolving the issue.
Change-Id: I3805361834f7d954ae6759a22f61f02db139bcc5
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This makes the following changes:
* re-orders the page to move the nova-network
specific information to the bottom
* creates two sections: one for CLI and one for
nova-network
* mentions at the top that by default neutron
manages security groups and their quota and
links to the neutron docs
* drops the mention of the 'nova' CLI since there
are no examples in this doc using that CLI
Change-Id: Ifd23424ac14bacf4bf7a0716c268f48ec869a41e
There is some important stuff in the admin/configuration
docs sub-tree like information about configuring hypervisor
drivers and scheduler filters/weighers but it wasn't easily
found since it wasn't in the admin toc tree. This adds it
to the overall admin home page and adds a TODO that we need
to organize that admin page into sections somehow.
Change-Id: I5952a2dd590407b1ce56805df6f90a472cc878bf
This adds a new config option to control the maximum number of disk
devices allowed to attach to a single instance, which can be set per
compute host.
The configured maximum is enforced when device names are generated
during server create, rebuild, evacuate, unshelve, live migrate, and
attach volume. When the maximum is exceeded during server create,
rebuild, evacuate, unshelve, or live migrate, the server will go into
ERROR state and the server fault will contain the reason. When the
maximum is exceeded during an attach volume request, the request fails
fast in the API with a 403 error.
The configured maximum on the destination is not enforced before cold
migrate because the maximum is enforced in-place only (the destination
is not checked over RPC). The configured maximum is also not enforced
on shelved offloaded servers because they have no compute host, and the
option is implemented at the nova-compute level.
Part of blueprint conf-max-attach-volumes
Change-Id: Ia9cc1c250483c31f44cdbba4f6342ac8d7fbe92b
Link to the "Secure live migration with QEMU-native TLS" document from
other relevant guides, and small blurbs of text where appropriate.
Blueprint: support-qemu-native-tls-for-live-migration
Change-Id: I9c6676897d27254e2e16bf7e36a74bf9f3da3832
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This spec proposes to add ability to allow users to use
``Aggregate``'s ``metadata`` to override the global config options
for weights to achieve more fine-grained control over resource
weights.
blueprint: per-aggregate-scheduling-weight
Change-Id: I6e15c6507d037ffe263a460441858ed454b02504
This resolves the TODO from Ocata change:
I8871b628f0ab892830ceeede68db16948cb293c8
By adding a min=0.0 value to the soft affinity
weight multiplier configuration options.
It also removes the deprecated [DEFAULT] group
alias from Ocata change:
I3f48e52815e80c99612bcd10cb53331a8c995fc3
Change-Id: I79e191010adbc0ec0ed02c9d589106debbf90ea8
Zuul