Turns out we've a *lot* of disparate metadata systems. Attempt to both
link them somewhat through extensive cross-referencing and extract out
deployment-specific stuff from user-facing docs. Lots of changes here,
but in summary:
- Split out admin-focused content from the metadata API, config drive,
user data and vendordata docs.
- Merge the config drive, metadata service, vendordata and user-data
user docs, which are mostly talking about the same thing and are
fairly barren without the deployment components
- Make use of various oslo.config and Sphinx roles
Side note: I miss when we have tech writers to do this stuff for us :(
Change-Id: I4fb2b628bd93358a752e2397ae353221758e2984
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Since blueprint return-alternate-hosts in Queens, the scheduler
returns a primary selected host and some alternate hosts based
on the max_attempts config option. The only reschedules we have
are during server create and resize/cold migrate. The list of
alternative hosts are passed down from conductor through compute
and back to conductor on reschedule and if conductor gets a list
of alternate hosts on reschedule it will not call the scheduler
again. This means the RetryFilter is effectively useless now since
it shouldn't ever filter out hosts on the first schedule attempt
and because we're using alternates for reschedules, we shouldn't
go back to the scheduler on a reschedule. As a result this change
deprecates the RetryFilter and removes it from the default list
of enabled filters.
Change-Id: Ic0a03e89903bf925638fa26cca3dac7db710dca3
This fixes a couple of places in the admin scheduler config
docs that were listing out the enabled_filters default value
incorrectly because the ComputeFilter was missing. Rather than
try to keep the docs mirrored with the actual default value,
this change references the config option in one spot and avoids
listing the defaults in another.
Change-Id: I837aefcd37556a7b66b523529c5ca1f3dee8ac7f
Closes-Bug: #1833120
We're going to remove all the code, but first, remove the docs.
Part of blueprint remove-consoleauth
Change-Id: Ie96e18ea7762b93b4116b35d7ebcfcbe53c55527
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Starting in noVNC v1.1.0, the token query parameter is no longer
forwarded via cookie [1]. We must instead use the 'path' query
parameter to pass the token through to the websocketproxy [2].
This means that if someone deploys noVNC v1.1.0, VNC consoles will
break in nova because the code is relying on the cookie functionality
that v1.1.0 removed.
This modifies the ConsoleAuthToken.access_url property to include the
'path' query parameter as part of the returned access_url that the
client will use to call the console proxy service.
This change is backward compatible with noVNC < v1.1.0. The 'path' query
parameter is a long supported feature in noVNC.
Co-Authored-By: melanie witt <melwittt@gmail.com>
Closes-Bug: #1822676
[1] https://github.com/novnc/noVNC/commit/51f9f0098d306bbc67cc8e02ae547921b6f6585c
[2] https://github.com/novnc/noVNC/pull/1220
Change-Id: I2ddf0f4d768b698e980594dd67206464a9cea37b
This removes the old reference to the nova-manage
command to refresh quota usage which no longer
applies since we started counting quotas in the
Pike release.
This replaces with a reference to the down-cell
known issue for counting quotas.
Change-Id: I2765f3ca3dc95345d4e4c4db43ac3dff4a509259
In May 2019, four new microprocessor security flaws, known as "MDS"
(Microarchitectural Data Sampling) have been discovered. These flaws
affect unpatched Nova Compute nodes and instances running on Intel
x86_64 CPUs. The said security flaws are also referred to as "RIDL"
(Rogue In-Flight Data Load) and "Fallout".
Refer to the following pages for further details:
- https://access.redhat.com/security/vulnerabilities/mds
- https://mdsattacks.com/
- https://zombieloadattack.com/
* * *
If we're adding the guide for "MDS" flaws, then it begs the
question: "What about mitigation guides for previous vulnerabilities?"
Two points:
(a) Write the mitigation document for rest of the previous
vulnerabilities too, for completeness' sake. (In April 2018 I wrote
this doc[1] for Meltdown — polish it and submit it. Parts of that
document's content is already incorporated into the help text for
the config attribute `cpu_model_extra_flags`.)
(b) For now, we can live with the cliché, "something is better than
nothing"; we'll add the other docs "when we get to it". Meanwhile,
operators get mitigation details from various other places —
processor vendors, Linux distributions, etc.
[1] https://kashyapc.fedorapeople.org/Reducing-OpenStack-Guest-Perf-Impact-from-Meltdown.txt
Change-Id: I1bb472c3438cc9a91945999d2350b2c59fa6a1f3
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This adds the missing "prefilter" stage to the description of the
scheduling process, and adds information about the image type
filter.
Related to blueprint request-filter-image-types
Change-Id: I07eef048cf2c85a3fdb8adbe38e362878e4e177e
This was put together while working on the mechanism for converting
driver capabilities to traits in I15364d37fb7426f4eec00ca4eaf99bec50e964b6:
https://review.openstack.org/538498
and may help other developers working on this area in the future.
Change-Id: I395e386ee713769d4c105be0dd6e821382945866
There was nothing clearly documented about move operations with
respect to AZ restrictions, i.e. when a server can move between
zones or not, and how forcing a target host during evacuate or
live migration can break tracking of the instance for it's orginally
intended zone. This adds documentation around that topic.
Change-Id: I7466826780ea8a6b3d3df93f0e85f009a437b743
Closes-Bug: #1823043
This commit adds a paragaph to explain the circumstances in which
disk_available_least will have a negative value, and why this behaviour is
preferred.
Change-Id: Iaa33c35a14a6f0dc8b1d11803a885dce26722e52
People hit problems using the JsonFilter from time to time
and at least I always have to re-learn what it does and am
somewhat horrified to find how flexible it is based on using
HostState attributes as filtering variables, not to mention
we don't do any functional testing with it. The docs are also
misleading in stating it only supports a subset of variables
when it's really anything on the HostState object. A common
case is people filtering on the hypervisor_hostname attribute
to schedule directly to a specific baremetal node with ironic.
This change adds a warning recommending to not use the filter
if possible and find alternatives, like traits. It also mentions
the HostState object as defining the variables that can be used
along with adding the commonly-used hypervisor_hostname variable
to the list.
Change-Id: Ib2b1395715b6bdb25f53ee7c68df44e2d84b895b
Related-Bug: #1821764
The API reference and part of the scheduler filter docs for
the JsonFilter query hint are using invalid json strings
in the examples.
This fixes both invalid locations using the same json string
used in the openstack server create command example in the
scheduler admin docs.
Change-Id: Iaab8608c7ffa6fbbea40a838dd02d8096f632f7a
Closes-Bug: #1821764
Now that we reshape inventories and allocations for VGPU resources in Stein,
we think it's good for operators to know how to verify the resources using
osc-placement.
Change-Id: Ic58709aac2dd1f20f1b8440a3cea4f29eed9a965
Closes-Bug: #1821015
FWIW, we already say in the feature classification documentation that the
feature is experimental [1] but we also now have functional tests that help
to verify that the feature is working.
I think we can just remove the note about this then.
[1] https://docs.openstack.org/nova/latest/user/feature-classification.html#operation_virtual_gpu
Change-Id: I705b3aeb1da33ddc41d4306ad91ad7cb70fcf4e4
Change I15364d37fb7426f4eec00ca4eaf99bec50e964b6 added the
ability for the compute service to report a subset of driver
capabilities as standard COMPUTE_* traits on the compute node
resource provider.
This adds administrator documentation to the scheduler docs
about the feature and how it could be used with flavors. There
are also some rules and semantic behavior around how these traits
work so that is also documented.
Note that for cases #3 and #4 in the "Rules" section the
update_available_resource periodic task in the compute service
may add the compute-owned traits again automatically but it
depends on the [compute]/resource_provider_association_refresh
configuration option, which if set to 0 will disable that auto
refresh and a restart or SIGHUP is required. To avoid confusion
in these docs, I have opted to omit the mention of that option
and just document the action that will work regardless of
configuration which is to restart or SIGHUP the compute service.
Change-Id: Iaeec92e0b25956b0d95754ce85c68c2d82c4a7f1
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
These were missed in I08991796aaced2abc824f608108c0c786181eb65.
Change-Id: Ibb31d7d8460c6376f42bcb65c94796d5e68f3d9d
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The admin and user flavor docs on pci.alias were not super
helpful by just throwing the user to the config docs or
flavor docs and letting them figure it out. This change
helps the reader by linking directly to the things being
referenced.
Also cleans up a pci.passthrough config option reference
while in here.
Change-Id: Ie2e28a14ff4655e38a5db3925adcd605ac773843
Remove wrong description for auto resize confirm
in the API guide.
Move a description of a configuration option
'resize_confirm_window' from the API guide
to the admin configuration guide.
Add a description of automatic resize confirm
in the user guide.
Change-Id: If739877422d5743e221c57be53ed877475db0647
Closes-Bug: #1816859
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
Adds a section in the admin guide with the config options related to
down cells.
Related to blueprint handling-down-cell
Change-Id: I6a6cc71e83896aaccd5dd98bc2ea024d6f22d528
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
As discussed in the mailing list [1] since cells v1
has been deprecated since Pike and the biggest user
of it (CERN as far as we know) moved to cells v2
in Queens, we can start rolling back the cells v1
specific documentation to avoid confusing people
new to nova about what cells is and making them
understand there was an optional v1.
There are still a few mentions of cells v1 left in
here for things like adding a new cell which need
to be re-written and for that I've left a todo.
Users can still get at cells v1 specific docs from
published stable branches and/or rebuilding the
docs from before this change.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002569.html
Change-Id: Idaa04a88b6883254cad9a8c6665e1c63a67e88d3
Stephen Finucane