These are no longer necessary with the removal of cells v1. A check for
cells v1 in 'nova-manage cell_v2 simple_cell_setup' is also removed,
meaning this can no longer return the '2' exit code.
Part of blueprint remove-cells-v1
Change-Id: I8c2bfb31224300bc639d5089c4dfb62143d04b7f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This resolves one of the TODOs in the heal_allocations CLI
by adding a --dry-run option which will still print the output
as we process instances but not commit any allocation changes
to placement, just print out that they would happen.
Change-Id: Ide31957306602c1f306ebfa48d6e95f48b1e8ead
Based on bug 1823104 it's clear we should have some
explicit wording in the notification reference docs
about what not to include in versioned notification
payloads, so this change attempts to start that with
the most obvious thing - don't expose access credentials
to the nova deployment.
This also adds a reminder to think about what is being
added / mirrored from internal objects and determine if
consumers really need it and if they aren't asking, opt
to not including it until requested.
Change-Id: I326aa39d963091282a5d0b70ba222abfe8ccfdac
Related-Bug: #1823104
This was added in Newton:
I97b72ae3e7e8ea3d6b596870d8da3aaa689fd6b5
And was meant to migrate keypairs from the cell
(nova) DB to the API DB. Before that though, the
keypairs per instance would be migrated to the
instance_extra table in the cell DB. The migration
to instance_extra was dropped in Queens with change:
Ie83e7bd807c2c79e5cbe1337292c2d1989d4ac03
As the commit message on ^ mentions, the 345 cell
DB schema migration required that the cell DB keypairs
table was empty before you could upgrade to Ocata.
The migrate_keypairs_to_api_db routine only migrates
any keypairs to the API DB if there are entries in the
keypairs table in the cell DB, but because of that blocker
migration in Ocata that cannot be the case anymore, so
really migrate_keypairs_to_api_db is just wasting time
querying the database during the online_data_migrations
routine without it actually migrating anything, so we
should just remove it.
Change-Id: Ie56bc411880c6d1c04599cf9521e12e8b4878e1e
Closes-Bug: #1822613
This patch adds a table of possible extra-spec/cpu_shared_set
combinations, and lists the expected behavior of instance emulator
threads for each case. This is an improvement over the previous doc,
which incorrectly implied that `share` was the default policy value,
and only covered what happens if cpu_shared_set is set.
Change-Id: Ia56607d0b70d5f46159b57ee1092ba0e37a02270
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
There is an inconsistency for keystone domain names
in the nova doc. ('default' and 'Default')
Replace 'default' with 'Default'.
Change-Id: I437092d04b0cbea78942efd5f565734f34bcbcb2
Closes-Bug: #1821411
This is a guide I used to help me throughout the cycle and I'm
proposing it to the docs, in case it might help someone.
Change-Id: I4f7600c908bf90395515f690b8eee0f9e7b0c9b0
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
We were seeing infinite recursion opening an ssl socket when running
various combinations of python3, eventlet, and urllib3. It is not
clear exactly what combination of versions are affected, but for
background there is an example of this issue documented here:
https://github.com/eventlet/eventlet/issues/371
The immediate cause in nova's case was that we were calling
eventlet.monkey_patch() after importing urllib3. Specifically, change
Ie7bf5d012e2ccbcd63c262ddaf739782afcdaf56 introduced the
nova.utils.monkey_patch() method to make monkey patching common
between WSGI and non-WSGI services. Unfortunately, before executing
this method you must first import nova.utils, which imports a large
number of modules itself. Anything imported (transitively) by
nova.utils would therefore be imported before monkey patching, which
included urllib3. This triggers the infinite recursion problem
described above if you have an affected combination of library
versions.
While this specific issue may eventually be worked around or fixed in
eventlet or urllib3, it remains true that eventlet best practises are
to monkey patch as early as possible, which we were not doing. To
avoid this and hopefully future similar issues, this change ensures
that monkey patching happens as early as possible, and only a minimum
number of modules are imported first.
This change fixes monkey patching for both non-wsgi and wsgi callers:
* Non-WSGI services (nova/cmd)
This is fixed by using the new monkey_patch module, which has minimal
dependencies.
* WSGI services (nova/api/openstack)
This is fixed both by using the new monkey_patch module, and by moving
the patching point up one level so that it is done before importing
anything in nova/api/openstack/__init__.py.
This move causes issues for some external tools which load this path
from nova and now monkey patch where they previously did not. However,
it is unfortunately unavoidable to enable monkey patching for the wsgi
entry point without major restructuring. This change includes a
workaround for sphinx to avoid this issue.
This change has been through several iterations. I started with what
seemed like the simplest and most obvious change, and moved on as I
discovered more interactions which broke. It is clear that eventlet
monkey patching is extremely fragile, especially when done implicitly at
module load time as we do. I would advocate a code restructure to
improve this situation, but I think the time would be better spent
removing the eventlet dependency entirely.
Co-authored-by: Lee Yarwood <lyarwood@redhat.com>
Closes-Bug: #1808975
Closes-Bug: #1808951
Change-Id: Id46e76666b553a10ec4654d4418a9884975b5b95
Add a description about sort order of response results in
the API reference guideline.
Change-Id: I458795a4f745a0699bc8de40aaa2b3c03c762422
Partial-Bug: #1793034
Some random cleanups:
- Don't add the root or 'doc/source' directories to PYTHONPATH - it's
unnecessary since we install nova (ruling out the first) and don't
import anything from the latter
- Fix weird indentation
- Remove 'sphinx.ext.coverage', which is used to measure API doc
coverage. This is unnecessary since we don't publish API docs, save
for the versioned notification docs
- Remove unnecessary settings
- 'exclude_patterns' referred to directories that haven't existed for
a long time
- 'source_suffix', 'add_module_names' and 'show_authors' were set to
the default value
- 'release', 'version' and 'html_last_updated_fmt' are all set
automatically by 'openstackdoctheme' now
- 'modindex_common_prefix' is useless since we don't expose a module
index
All rolled into one patch for efficiencies sake.
Change-Id: I0f70c6d71299dedc59884f2bb39c8ea3c2ca8eff
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
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
This commit updates the list of issues with policy enforcement and
describe some of the benefits for operators and developers if we fix
these issues.
Change-Id: Ie5ba2375fd32611aca360765af01c1ba6432b45e
This is removing additional details that were originally reviewed in:
I263b2f72037a588623958baccacf78fb6a6be05d
The policy and docs in code work that nova completed in Newton.
Change-Id: I66105fa90036db50249b62fc34442b667a5ee1db
The policy-enforcement document was written prior to any of the
policy-in-code or policy documentation efforts took place. This
commit updates the developer reference for policy to remove these
details since they have already been implemented.
Subsequent patches will update details of this document by taking into
account the recent keystone and oslo changes that help fix the
original issues described in this document.
Change-Id: I263b2f72037a588623958baccacf78fb6a6be05d
Blueprint detach-service-from-computenode in Kilo decoupled the
compute node and services concepts so this section is no longer
relevant and can be removed from the doc - it's no longer evolving.
Change-Id: Ibba2aa83b0afe2be05415b69a1ff8ae86866b860
Related-Bug: #1820283
Since I901184cb1a4b6eb0d6fa6363bc6ffbcaa0c9d21d in Kilo the
aggregates information about a HostState object (which is a
wrapper over a ComputeNode) is cached in the scheduler, so the
comments in the scheduler evolution doc about not accessing the
aggregates table in the DB from filters/weighers and such is
extremely out of date and should just be removed.
Change-Id: Ibcbad227813d3b37b4e314eddbf3bae6e85652ea
Related-Bug: #1820283
This document was written back in the liberty release [1]
and says that conductor is not used for orchestrating the
resize/migrate flow, but given the description of how
conductor is used to orchestrate scheduling and reschedules
during a server create, it is unclear why the doc says that
resize is not used the same way since it is used for rescheduling
when prep_resize fails in a selected dest compute. This removes
the caveat to reflect reality.
[1] Ieb9134302d21a11fe9b9ee876bb7b0dd32b437e1
Change-Id: I932a7ac6870a3f9d26556c23c9074115963b3c27
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
Stephen Finucane