This change mainly fixes incorrect use of backticks
but also adress some other minor issues like unbalanced
backticks, incorrect spacing or missing _ in links.
This change add a tox target to run sphinx-lint
as well as adding it to the relevent tox envs to enforce
it in ci. pre-commit is leveraged to install and execute
sphinx-lint but it does not reqiure you to install the
hooks locally into your working dir.
Change-Id: Ib97b35c9014bc31876003cef4362c47a8a3a4e0e
The 'force' parameter of os-brick's disconnect_volume() method allows
callers to ignore flushing errors and ensure that devices are being
removed from the host.
We should use force=True when we are going to delete an instance to
avoid leaving leftover devices connected to the compute host which
could then potentially be reused to map to volumes to an instance that
should not have access to those volumes.
We can use force=True even when disconnecting a volume that will not be
deleted on termination because os-brick will always attempt to flush
and disconnect gracefully before forcefully removing devices.
Closes-Bug: #2004555
Change-Id: I3629b84d3255a8fe9d8a7cea8c6131d7c40899e8
We had recent bug report about a possible regression related to
affinity policy enforcement with parallel server create requests.
It turned out not to be a regression but because of the complexity
around affinity enforcement, it might help to add a section to the
compute troubleshooting doc about it which we could refer to in the
future.
Related-Bug: #1863190
Change-Id: I508c48183a7205d46e13154d4e92d31dfa7f7d78
This has come up a few times via support questions from operators
that have a nova cell database out of sync with the placement
database resulting in a mismatch in compute nodes to provider
uuids and they just want to wipe the placement database and rebuild
it from the current data in nova. This provides a document with the
high level steps to do that.
Change-Id: Ie4fed22615f60e132a887fe541771c447fae1082
While we do not have an automated fix for bug 1849479 this provides
a troubleshooting document for working around that issue where
allocations from a server that was evacuated from a down host need
to be cleaned up manually in order to delete the resource provider
and associated compute node/service.
In general this is also a useful guide for linking up the various
resources and terms in nova and how they are reflected in placement
with the relevant commands which is probably something we should
do more of in our docs.
Change-Id: I120e1ddd7946a371888bfc890b5979f2e19288cd
Related-Bug: #1829479
Keystonemiddleware compares the roles of the service_user with
[Keystone_authtoken]/service_token_roles, we need to explain this so
that users don't get confused.
For example:
Nova send request to neutron with both service_user_token and
user_token, neutron first sends them to Keystonemiddleware for
authenrication, Keystonemiddleware will compare service_user's role
with [Keystone_authtoken]/service_token_roles which configured in
neutron, then decide whether to fetch user_token based on the result.
Change-Id: I024885adad2d14bc2568382c677198132dc88a13
This was added to handle gate issues seen with libvirt 1.2.2. We haven't
supported that version of libvirt for some time and we don't enable this
in the gate anymore. Deprecate it and remove unnecessary references to
it from tests and the support FAQ document.
Change-Id: Ie3fa537a42d208a35467f03bd2110c2976927477
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>
We typically use '-' for H2-type headers and '~' for H3-style. This
document was using the opposite which was mighty confusing for your dear
editor. Simply switch them around and reduce that confusion.
Change-Id: I69712bab7deeb75b3fe619c9d93a078f90b76dad
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
A recent thread in the mailing list [1] reminded me that we
don't have any documentation for the service user token feature
added back in ocata under blueprint use-service-tokens.
This change adds a troubleshooting entry for when using service
user tokens would be useful, and links to it from two known
trouble spots: live migration timeouts and creating images.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001130.html
Change-Id: I1dda889038ffe67d53ceb35049aa1f2a9da39ae8
Closes-Bug: #1809165
If the compute endpoint in the service catalog is configured
for /v2 legacy compat mode, microversions in the request are
silently ignored by the LegacyV2CompatibleWrapper. This
adds a troubleshooting entry for that situation.
At this point, we might want to consider deprecating or at
least logging warnings if microversions are requested and
LegacyV2CompatibleWrapper strips them out, but that's fodder
for a separate change.
Change-Id: Ia7ecbf95d0a3e14c7f82b6a93c2ac4c4cfb89549
Import the following documents from the admin guide [1]:
- cli-manage-flavors.rst
- cli-nova-evacuate.rst
- cli-nova-manage-projects-security.rst
- cli-nova-manage-services.rst
- cli-nova-numa-libvirt.rst
- cli-nova-specify-host.rst
- cli-set-quotas.rst
- cli-set-compute-quotas.rst
- cli-os-migrate.rst
- cli-os-migrate-cfg-ssh.rst
- ts-no-emulator-x86-64.rst
- ts-multipath-warn.rst
- ts-failed-connect-vol-FC-SAN.rst
- ts-failed-attach-vol-no-sysfsutils.rst
- ts-failed-attach-vol-after-detach.rst
- ts-vol-attach-miss-sg-scan.rst
These were missed in the original import [2]. All 'ts-' files are merged
into a single 'support-compute' document, which is already in-tree.
[1] https://github.com/openstack/openstack-manuals/tree/stable/ocata/doc/admin-guide/source
[2] https://review.openstack.org/#/c/477497/
Change-Id: Ifa0039e270e54ea2fb58ab18ce6724e5e8e061a1
Closes-Bug: #1708666
Import all docs from openstack-manuals.
Part of bp: doc-migration
Change-Id: I28bb8ce1f4a8653f176a554d2e95b4423c437972
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>