We have droped the system scope from Nova policy
and keeping the legacy admin behaviour same. This
commit adds the releasenotes and update the policy
configuration documentation accordingly.
Also, remove the upgrade check for policy which was
added for the system scope configuration protection.
Change-Id: I127cc4da689a82dbde07059de90c451eb09ea4cf
To implement the usage of same_subtree query parameter in the
allocation candidate request first the minimum requires placement
microversion needs to be bumped from 1.35 to 1.36. This patch makes such
bump and update the related nova upgrade check. Later patches will
modify the query generation to include the same_subtree param to the
request.
Change-Id: I5bfec9b9ec49e60c454d71f6fc645038504ef9ef
blueprint: qos-minimum-guaranteed-packet-rate
I don't actually grok what this does that 'oslopolicy-checker' couldn't
do, so perhaps we can deprecate this in the future. For now though,
simply document the thing. While we're here, we make some additional
related changes:
- Remove references to the 'policy.yaml' file for services that don't
use policy (i.e. everything except the API services and, due to a bug,
the nova-compute service).
- Update remaining references to the 'policy.yaml' file to include the
'policy.d/' directory
- Update the help text for the '--api-name' and '--target' options of
the 'nova-policy policy check' command to correct tense and better
explain their purpose.
Also, yes, 'nova-policy policy check' is dumb. Don't blame me :)
Change-Id: I913b0de9ec40a615da7bf9981852edef4a88fecb
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Related-bug: #1675486
This change introduces a new nova-status check to ensure a machine type
has been recorded for each instance within an environment.
nova-status will fail with a warning when instances are found, directing
the operator to use the previously added nova-manage list_unset and
update commands to set a machine type for these instances. The logic for
this check comes entirely from the list_unset command.
It is noted in the warning output that this can be ignored if no libvirt
or HyperV based computes are present in the environment as
hw_machine_type is only used by these two virt drivers at present.
blueprint: libvirt-default-machine-type
Change-Id: Ic3ae48c57e61c4e45883fbae1328a448be025953
Report a warning during upgrade checks if there are computes older than
the previous major nova release in the system.
So if code is upgraded to Wallaby and the upgrade check was run before
the restart of the services with W code then the check warns for Ussuri
computes in the system.
Change-Id: I873b0c1e6e695ae88241bbf75ac9f80ecc6f5664
Default value of 'CONF.oslo_policy.policy_file' config option
has been changed from 'policy.json' to 'policy.yaml'. If new default
file 'policy.yaml' does not exist but old default 'policy.json' exist
then fallback to use old default file.
An upgrade checks is added to check the policy_file format and
fail upgrade checks if it is JSON formatted.
Added a warning in policy doc about JSON formatted file is deprecated,
also removed all the reference to policy.json file in doc as well as
in tests.
Related Blueprint: policy-json-to-yaml
Closes-Bug: #1875418
Change-Id: Ic4d3b998bb9701cb1e3ef12d9bb6f4d91cc19c18
These do not render correctly when generating man pages and likely exist
from a time when the pages were built with rst2man (i.e. docutils)
instead of Sphinx. They're not necessary when using Sphinx since that
information is provided via the 'man_pages' config option in 'conf.py',
which are updated here to reflect reality.
Change-Id: I133e7231112cc9025e57a29d43bfa7002ca775e7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
There are cases where policy file is re-generated freshly
and end up having the new defaults only but expectation is that
old deprecated rule keep working.
If a rule is present in policy file then, that has priority over
its defaults so either rules should not be present in policy file
or users need to update their token to match the overridden rule
permission.
This issue was always present when any policy defaults were changed
with old defaults being supported as deprecated. This is we have
changed all the policy for new defaults so it came up as broken case.
Adding nova-status upgrade check also to detect such policy file.
Related-Bug: #1875418
Change-Id: Id9cd65877e53577bff22e408ca07bbeec4407f6e
Placement microversion 1.35 gives us the root_required queryparam to GET
/allocation_candidates, allowing us to filter out candidates where the
*root* provider has/lacks certain traits, independent of traits
specified in any of the individual request groups.
Use it.
And add affordance for specifying such traits to the RequestSpec.
Which allows us to fix up the couple of request filters that were
hacking traits into the RequestSpec.flavor.
Change-Id: I44f02044ce178e84c23d178e5a23a3aa1208e502
This commit cuts us over to using placement microversion 1.34 for GET
/allocation_candidates, thereby supporting string request group suffixes
(added in 1.33) when specified in flavor extra_specs.
The mappings (added in 1.34) are not used in code yet, but a future
patch will tie the group suffixes to the RequestGroup.requester_id so
that it can be correlated after GET /a_c. This will allow us to get rid
of map_requested_resources_to_providers, which was a hack to bridge the
gap until we had mappings from placement.
Change-Id: I52499ff6639c1a5815a8557b22dd33106dcc386b
This patch modifies Nova objects that will allow Destination object to
store list of forbidden aggregates that placement should ignore in
'GET /allocation_candidates' API at microversion 1.32, including the
code to generate the placement querystring syntax from them.
Change-Id: Ic2bcee40b41c97170a8603b27b935113f0633de7
Implements: blueprint placement-req-filter-forbidden-aggregates
The "Request Spec Migration" upgrade status check was added
in Rocky [1] and the related online data migration was removed
in Stein [2]. Now that we're in Train we should be able to
remove the upgrade status check.
The verify install docs are updated to remove the now-removed
check along with "Console Auths" which were removed in Train [3].
[1] I1fb63765f0b0e8f35d6a66dccf9d12cc20e9c661
[2] Ib0de49b3c0d6b3d807c4eb321976848773c1a9e8
[3] I5c7e54259857d9959f5a2dfb99102602a0cf9bb7
Change-Id: I6dfa0b226ab0b99864fc27209ebb7b73e3f73512
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>
The compute API has required cinder API >= 3.44 since Queens [1] for
working with the volume attachments API as part of the wider
volume multi-attach support.
In order to start removing the compatibility code in the compute API
this change adds an upgrade check for the minimum required cinder API
version (3.44).
[1] Ifc01dbf98545104c998ab96f65ff8623a6db0f28
Change-Id: Ic9d1fb364e06e08250c7c5d7d4bdb956cb60e678
This patch adds the translation of `RequestGroup.in_tree` to the
actual placement query and bumps microversion to enable it.
The release note for this change is added.
Change-Id: I8ec95d576417c32a57aa0298789dac6afb0cca02
Blueprint: use-placement-in-tree
Related-Bug: #1777591
With change I11083aa3c78bd8b6201558561457f3d65007a177
the code for the API Service Version upgrade check no
longer exists and therefore the upgrade check itself
is meaningless now.
Change-Id: I68b13002bc745c2c9ca7209b806f08c30272550e
With placement being extracted from nova, the
"Resource Providers" nova-status upgrade check no
longer works as intended since the placement data
will no longer be in the nova_api database. As a
result the check can fail on otherwise properly
deployed setups with placement extracted.
This check was originally intended to ease the upgrade
to Ocata when placement was required for nova to work,
as can be seen from the newton/ocata/pike references
in the code.
Note that one could argue the check itself as a concept
is still useful for fresh installs to make sure everything
is deployed correctly and nova-compute is properly
reporting into placement, but for it to be maintained
we would have to change it to no longer rely on the
nova_api database and instead use the placement REST API,
which while possible, might not be worth the effort or
maintenance cost.
For simplicity and expediency, the check is simply removed
in this change.
Related mailing list discussion can be found here [1].
[1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000454.html
Change-Id: I630a518d449a64160c81410245a22ed3d985fb01
Closes-Bug: #1808956
Placement documents have been published since
I667387ec262680af899a628520c107fa0d4eec24.
So use links to placement documents
https://docs.openstack.org/placement/latest/
in nova documents.
Change-Id: I218a6d11fea934e8991e41b4b36203c6ba3e3dbf
This will check if a deployment is currently using consoles and warns
the operator to set [workarounds]enable_consoleauth = True on their
console proxy host if they are performing a rolling upgrade which is
not yet complete.
Partial-Bug: #1798188
Change-Id: Idd6079ce4038d6f19966e98bcc61422b61b3636b
Add a thin wrapper to invoke the POST /reshaper placement API with
appropriate error checking. This bumps the placement minimum to the
reshaper microversion, 1.30.
Change-Id: Idf8997d5efdfdfca6967899a0882ffb9ecf96915
blueprint: reshape-provider-tree
If we're updating existing allocations for an instance due
to the project_id/user_id not matching the instance, we should
use the consumer_generation parameter, new in placement 1.28,
to ensure we don't overwrite the allocations while another
process is updating them.
As a result, the include_project_user kwarg to method
get_allocations_for_consumer is removed since nothing else
is using it now, and the minimum required version of placement
checked by nova-status is updated to 1.28.
Change-Id: I4d5f26061594fa9863c1110e6152069e44168cc3
We can't easily add a blocker db sync migration to make
sure the migrate_instances_add_request_spec online data
migration has been run since we have to iterate both cells
(for instances) and the API DB (for request specs) and that's
not something we should do during a db sync call.
But we want to eventually drop the online data migration and
the accompanying compat code found in the api and conductor
services.
This adds a nova-status upgrade check for missing request specs
and fails if any existing non-deleted instances are found which
don't have a matching request spec.
Related to blueprint request-spec-use-by-compute
Change-Id: I1fb63765f0b0e8f35d6a66dccf9d12cc20e9c661
Change I496e8d64907fdcb0e2da255725aed1fc529725f2 made nova-scheduler
require placement >= 1.25 so this change updates the minimum required
version checked in the nova-status upgrade check command along with the
upgrade docs.
related to blueprint: granular-resource-requests
Change-Id: I0a17ee362461a8ae2113804687799bb9d9216110
Change Id7eecbfe53f3a973d828122cf0149b2e10b8833f made
nova-scheduler require placement >= 1.24 so this change
updates the minimum required version checked in the
nova-status upgrade check command along with the upgrade
docs.
Change-Id: I4369f7fb1453e896864222fa407437982be8f6b5
This ensures we have version-specific references to other projects [1].
Note that this doesn't mean the URLs are actually valid - we need to do
more work (linkcheck?) here, but it's an improvement nonetheless.
[1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper
Change-Id: Ifb99e727110c4904a85bc4a13366c2cae300b8df
This is done in a couple of places in the documentation and is broken
rST. 'prog' is semantic markup that fits right in here, so use that.
Change-Id: Ic654e33daaf68b01f561ac8d792934d5a57a07e5
Change Ib984c30543acb3ca9cb95fb53d44d9ded0f5a5c8, which was added
in Newton when cells v2 was optional, added some transitional code
to the API for looking up an instance, which didn't rely on instance
mappings in a cell to find the instance if the minimum nova-osapi_compute
service version was from before Ocata.
People have reported this being a source of confusion when upgrading
from before Ocata, when cells v2 wasn't required, to Ocata+ where cells
v2 along with the mapping setup is required. That's because they might
have older nova-osapi_compute service version records in their 'nova'
(cell) database which makes the API think the code is older than it
actually is, and results in an InstanceNotFound error.
This change does two things:
1. Adds a warning to the compute API code in this scenario to serve
as a breadcrumb if a deployment hits this issue.
2. A nova-status check to look for minimum nova-osapi_compute service
versions across all cells and report the issue as a warning. It's
not an upgrade failure since we don't know how the nova-api service
is configured, but leave that investigation up to the deployer.
This is also written in such a way that we should be able to backport
this through to stable/ocata.
Change-Id: Ie2bc4616439352850cf29a9de7d33a06c8f7c2b8
Closes-Bug: #1759316
In Pike we started requiring that ironic instances have their
embedded flavor migrated to track the ironic node custom
resource class. This can be done either via the normal running
of the nova-compute service and ironic driver or via the
'nova-manage db ironic_flavor_migration' command.
This change adds a nova-status check to see if there are any
unmigrated ironic instances across all non-cell0 cells, and
is based mostly on the same logic within the nova-manage command
except it's multi-cell aware and doesn't use the objects.
Change-Id: Ifd22325e849db2353b1b1eedfe998e3d6a79591c
This uses the member_of query parameter to placement to ensure that the
candidates returned are within the appropriate aggregate(s) if so
specified.
Related to blueprint placement-req-filter
Change-Id: If8ac06039ac9d647efdc088fbe944938e205e941
This patch removes the unnecessary maintenance of a date and version
from the CLI documentation.
NOTE: Cinder team also did the same removal with
the commit Idf78bbed44f942bb6976ccf4da67c748d9283ed9
Change-Id: I0a9dd49e68f2d47c58a46b107c77975e7b2aeaf7
This patch enables the flavor extra spec 'required:[traits]'. The
admin can specifiy a set of traits that a flavor required.
To enable this, the placement 1.17 is required, it added trait
support in the `GET /allocation_candidates` API. So bump the
minimal placement version requirement to 1.17 and update the
check in cmd `nova-status`.
Implement blueprint request-traits-in-nova
Change-Id: Ia51ace951e9a0402f873ce9751a8cd3c0283db08
With change I2f367b06e683ed7c815dd9e0536a46e5f0a27e6c, nova-compute
now unconditionally requires Placement 1.14 to be available (the
client side code doesn't check to see if 1.14 is available before
trying to use it).
This change updates the nova-status check for the minimum required
version of Placement and also starts the "Queens" section of the
Placement upgrade notes docs.
Change-Id: I37415e384d375bc9b548a0223f787a9236286bb0
Rework the man pages by:
- Wording the synopsis sections similarly for all commands
- Not using upper-case section names, as this is unnecessary and results
in worse HTML output
- Formatting code and file names as literals
The 'nova-idmapshift' man page is excluded as this utility will be
removed shortly.
Change-Id: I67914a757f9436461960a8d6b92d157f59ccad66
Per the spec [1]:
cli/ – command line tool reference docs, similar to man pages These
may be automatically generated with cliff's sphinx integration, or
manually written when auto-generation is not possible.
All of the docs currently found in 'man' fit that category, so those and
those alone are moved. It'll be a great day in the parish when we can
replace all of these with cliff's Sphinx integration.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I45bed324ec37cfea7c1a574ec06af38e7b875a1c
ghanshyam mann