this is the inital patch of applying codespell to nova.
codespell is a programing focused spellchecker that
looks for common typos and corrects them.
i am breaking this into multiple commits to make it simpler
to read and will automate the execution of codespell
at the end of the series.
Change-Id: If24a6c0a890f713545faa2d44b069c352655274e
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
The PowerVM driver was deprecated in November 2021 as part of change
Icdef0a03c3c6f56b08ec9685c6958d6917bc88cb. As noted there, all
indications suggest that this driver is no longer maintained and may be
abandonware. It's been some time and there's still no activity here so
it's time to abandon this for real.
This isn't as tied into the codebase as the old XenAPI driver was, so
removal is mostly a case of deleting large swathes of code. Lovely.
Change-Id: Ibf4f36136f2c65adad64f75d665c00cf2de4b400
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
After moving the nova APIs policy as per the new guidlines
where system scoped token will be only allowed to access
system level APIs and will not be allowed any operation
on project level APIs. With that we do not need below
base rules (who have hardcoded 'system_scope:all' check_str):
- system_admin_api
- system_reader_api
- system_admin_or_owner
- system_or_project_reader
At this stage (phase-1 target), we allow below roles as targeted
in phase-1 [1]
1. ADMIN(this is System Administrator with scope_type 'system'
when scope enabled otherwise legacy admin)
2. PROJECT_ADMIN
3. PROJECT_MEMBER
4. PROJECT_READER
& below one specific to nova
5. PROJECT_READER_OR_ADMIN (to allow system admin and project reader
to list flavor extra specs)
This complete the phase-1 of RBAC community-wide goal[2] for nova.
Add release notes too.
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#how-operator
[2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#yoga-timeline-7th-mar-2022
Partial implement blueprint policy-defaults-refresh-2
Change-Id: I075005d13ff6bfe048bbb21d80d71bf1602e4c02
Take the opportunity to clean up the docs quite a bit, ultimately
combining two disparate guides on the scheduler into one.
Change-Id: Ia72d39b4774d93793b381359b554c717dc9a6994
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Nova does not support all the scope provided by
keystone. It is better to mention the supported
scope and default roles.
Also adding a table to map the legacy rules with new
rules.
Change-Id: If7f025b3eaeda2df0cb1efd567b8fc60e274d09c
Turns out oslo.config actually supports executable-specific
configuration files as well as directories of configuration files. Who
knew?
Change-Id: Ifb71a45ed4df3c9cacd2193beed904f948f5cdc8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This beefy patch closes a long-standing TODO and allows us to move yet
more information out of the flavors guide and into specific documents.
This, combined with existing documentation in place, means we can remove
the sections for various extra specs from the 'user/flavors' guide:
- hw:cpu_realtime -> doc/source/admin/real-time.rst
- hw:cpu_realtime_mask -> doc/source/admin/real-time.rst
- hw:emulator_threads_policy -> doc/source/admin/cpu-topologies.rst
- hw:cpu_policy -> doc/source/admin/cpu-topologies.rst
- hw:cpu_thread_policy -> doc/source/admin/cpu-topologies.rst
- hw:cpu_sockets -> doc/source/admin/cpu-topologies.rst
- hw:cpu_cores -> doc/source/admin/cpu-topologies.rst
- hw:cpu_threads -> doc/source/admin/cpu-topologies.rst
- hw:cpu_max_sockets -> doc/source/admin/cpu-topologies.rst
- hw:cpu_max_cores -> doc/source/admin/cpu-topologies.rst
- hw:cpu_max_threads -> doc/source/admin/cpu-topologies.rst
- hw:numa_nodes -> doc/source/admin/cpu-topologies.rst
- hw:numa_cpus.N -> doc/source/admin/cpu-topologies.rst
- hw:numa_mem.N -> doc/source/admin/cpu-topologies.rst
- hw:mem_page_size -> doc/source/admin/huge-pages.rst
Multiple improvements to the libvirt extra spec docs are included here,
for want of a better place to include them.
Change-Id: I02b044f8246f4a42481bb5f00259842692b29b71
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
policy file default and JSON format 'policy.json' is now
deprecated. Let's replace all the ref and test start using the
policy.yaml.
Change-Id: I78a273576702fb95d831bd9b801b5774fb9fd19e
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
This commit adds the documents to explain the new defaults,
migration plan and releases notes for policies changes in
BP policy-defaults-refresh
Partial implement blueprint policy-defaults-refresh
Change-Id: I00e678858a8e46786f3b69fbba3f5353932de49b
Now that we have a registry of all extra specs known by stock nova, we
can start documenting these. We choose the configuration guide to do
this since configuration of flavor extra specs is traditionally an
admin-only operation.
Part of blueprint flavor-extra-spec-validators
Change-Id: I5ad6576e0d31a29822d1c7b47751ea81828630cf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is a follow-up patch for https://review.opendev.org/676730.
In the TOC of the current PDF file [1], most contents related to
user and admin guides are located under "For Contributors" section.
This is weird. It happens because the latex builder constructs
the document tree based on "toctree" directives even though they
are marked as "hidden".
This commit reorganizes "toctree" per section.
The "toctree" directives must be placed at the end of
individual sections. Otherwise, content of a last section and
content just after "toctree" directive are concatenated
into a same section in the rendered LaTeX document.
This commit also improves the following as well:
* Specify "openany" as "extraclassoptions" to skip blank pages
along with "oneside" to use same page style for odd and even pages.
* Set "tocdepth" and "secnumdepth" to 3 respectively.
"tocdepth" controls the depth of TOC and "secnumdepth" controls
the level of numbered sections in TOC.
Note that this commit does not reorganize file structure under doc/source.
I believe this should be done separately.
[1] https://docs.openstack.org/nova/latest/doc-nova.pdf
Change-Id: Ie9685e6a4798357d4979aa6b4ff8a03663a9c71c
Story: 2006100
Task: 35140
- Add a new pdf-docs environment to enable PDF build.
- sphinxcontrib-svg2pdfconverter is used to handle SVG properly.
- maxlistdepth=10 in latex_elements is needed to handle
deeper levels of nesting.
- Sample config/policy files are skipped in the PDF document
as inline sample files cause LaTeX error [1] and direct links
in PDF doc is discouraged. Note that sample-config and sample-policy
need to be excluded to avoid the LaTeX error [1] and
:orphan: is specified in those files.
[1] https://github.com/sphinx-doc/sphinx/issues/3099
Change-Id: I3aaea1d15a357f550f529beaa84fb1a1a7748358
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 adds a granular policy checking framework for
placement based on nova.policy but with a lot of
the legacy cruft removed, like the is_admin and
context_is_admin rules.
A new PlacementPolicyFixture is added along with
a new configuration option, [placement]/policy_file,
which is needed because the default policy file
that gets used in config is from [oslo_policy]/policy_file
which is being used as the nova policy file. As
far as I can tell, oslo.policy doesn't allow for
multiple policy files with different names unless
I'm misunderstanding how the policy_dirs option works.
With these changes, we can have something like:
/etc/nova/policy.json - for nova policy rules
/etc/nova/placement-policy.yaml - for placement rules
The docs are also updated to include the placement
policy sample along with a tox builder for the sample.
This starts by adding granular rules for CRUD operations
on the /resource_providers and /resource_providers/{uuid}
routes which use the same descriptions from the placement
API reference. Subsequent patches will add new granular
rules for the other routes.
Part of blueprint granular-placement-policy
Change-Id: I17573f5210314341c332fdcb1ce462a989c21940
The top level index (home page) was duplicating the
configuration/index content, so this simply changes
the home page into a table of contents for the configuration
sub-tree and leaves the config/policy content in the
sub-tree. This will be needed when we add docs about
placement policy.
The hidden configuration toc tree items are moved
into the sub-tree configuration/index to be closer
to the actual documents we're hiding from the toc tree.
Related to blueprint granular-placement-policy
Change-Id: Iad87dc339278ee7e7cf8de5eea252bbb7a5f75c2
Providing a sample policy file is all well and good, but it's not
exactly designed for readability on the web. Make use of the 'sphinxext'
module built into oslo.policy to do this.
Change-Id: I6cceeca7edcacb762daa1f22f2138e2d2334b3a2
Providing a sample configuration file is all well and good, but it's not
exactly designed for readability on the web. Make use of the 'sphinxext'
module built into oslo.config to do this.
Change-Id: I75e8f0adae7cfaaa6020870cdb20dc2144fc70eb
Per the spec [1]:
configuration/ – automatically generated configuration reference
information based on oslo.config’s sphinx integration (or manually
written for projects not using oslo.config). Step-by-step guides for
doing things like enabling cells or configuring a specific driver
should be placed in the admin/ section.
Only the 'sample_policy' and 'sample_config' files fit into this
category at present. We may wish to add files that use the oslo.config
and oslo.policy Sphinx integrations, but that can come later.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I587551ada1932876bca51a362f8dfeef6f7dd70b