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
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
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
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
- 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
Matt Riedemann