From f750cb2d83511e8d11791002a270d1dbc1f59056 Mon Sep 17 00:00:00 2001 From: Doug Goldstein Date: Mon, 4 Aug 2025 22:06:23 -0500 Subject: [PATCH] chore: use sphinx-lint on the docs and releasenotes Enable sphinx-lint via pre-commit and fix up the existing issues. The most common one was single backtick vs double backtick. In ReStructured Text you must use a double backtick while Markdown uses the single backtick for a fixed-width font. The other issue was a tabs vs spaces change in a file. Change-Id: I28e91272d67d13db0fefaa7165e0ba887086eae9 Signed-off-by: Doug Goldstein --- .pre-commit-config.yaml | 6 ++ doc/source/devref/fluent-logging.rst | 2 +- doc/source/devref/networking.rst | 38 +++++----- doc/source/specs/2025.1/chart_versioning.rst | 70 +++++++++---------- .../specs/2025.2/own_service_accounts.rst | 40 +++++------ doc/source/specs/multi-os.rst | 4 +- doc/source/specs/osh-1.0-requirements.rst | 12 ++-- doc/source/testing/ceph-upgrade.rst | 30 ++++---- .../troubleshooting/persistent-storage.rst | 2 +- 9 files changed, 105 insertions(+), 99 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 1ce346df69..7cd9bd6c70 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -8,3 +8,9 @@ repos: - id: mixed-line-ending args: ['--fix', 'lf'] - id: check-merge-conflict + - repo: https://github.com/sphinx-contrib/sphinx-lint + rev: v1.0.0 + hooks: + - id: sphinx-lint + args: [--enable=default-role] + files: ^doc/|releasenotes diff --git a/doc/source/devref/fluent-logging.rst b/doc/source/devref/fluent-logging.rst index 5c8291f93a..ce04c36cd2 100644 --- a/doc/source/devref/fluent-logging.rst +++ b/doc/source/devref/fluent-logging.rst @@ -21,7 +21,7 @@ log aggregator and processor. Fluent-bit, Fluentd meet OpenStack-Helm's logging requirements for gathering, aggregating, and delivering of logged events. Fluent-bit runs as a daemonset on -each node and mounts the `/var/lib/docker/containers` directory. The Docker +each node and mounts the ``/var/lib/docker/containers`` directory. The Docker container runtime engine directs events posted to stdout and stderr to this directory on the host. Fluent-bit then forward the contents of that directory to Fluentd. Fluentd runs as deployment at the designated nodes and expose service diff --git a/doc/source/devref/networking.rst b/doc/source/devref/networking.rst index 4640b11b92..b0199a0e79 100644 --- a/doc/source/devref/networking.rst +++ b/doc/source/devref/networking.rst @@ -37,7 +37,7 @@ Typical networking API request is an operation of create/update/delete: * port Neutron-server service is scheduled on nodes with -`openstack-control-plane=enabled` label. +``openstack-control-plane=enabled`` label. neutron-rpc-server ~~~~~~~~~~~~~~~~~~ @@ -77,7 +77,7 @@ implementing the interface. You can see the endpoints to class mapping in `setup.cfg `_. If the SDN of your choice is using the ML2 core plugin, then the extra -options in `neutron/ml2/plugins/ml2_conf.ini` should be configured: +options in ``neutron/ml2/plugins/ml2_conf.ini`` should be configured: .. code-block:: ini @@ -92,10 +92,10 @@ options in `neutron/ml2/plugins/ml2_conf.ini` should be configured: mech_drivers = openvswitch, l2population SDNs implementing ML2 driver can add extra/plugin-specific configuration -options in `neutron/ml2/plugins/ml2_conf.ini`. Or define its own `ml2_conf_.ini` +options in ``neutron/ml2/plugins/ml2_conf.ini``. Or define its own ``ml2_conf_.ini`` file where configs specific to the SDN would be placed. -The above configuration options are handled by `neutron/values.yaml`: +The above configuration options are handled by ``neutron/values.yaml``: .. code-block:: yaml @@ -119,7 +119,7 @@ The above configuration options are handled by `neutron/values.yaml`: Neutron-rpc-server service is scheduled on nodes with -`openstack-control-plane=enabled` label. +``openstack-control-plane=enabled`` label. neutron-dhcp-agent ~~~~~~~~~~~~~~~~~~ @@ -127,7 +127,7 @@ DHCP agent is running dnsmasq process which is serving the IP assignment and DNS info. DHCP agent is dependent on the L2 agent wiring the interface. So one should be aware that when changing the L2 agent, it also needs to be changed in the DHCP agent. The configuration of the DHCP agent includes -option `interface_driver`, which will instruct how the tap interface created +option ``interface_driver``, which will instruct how the tap interface created for serving the request should be wired. .. code-block:: yaml @@ -170,14 +170,14 @@ There is also a need for DHCP agent to pass ovs agent config file --config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini {{- end }} -This requirement is OVS specific, the `ovsdb_connection` string is defined -in `openvswitch_agent.ini` file, specifying how DHCP agent can connect to ovs. +This requirement is OVS specific, the ``ovsdb_connection`` string is defined +in ``openvswitch_agent.ini`` file, specifying how DHCP agent can connect to ovs. When using other SDNs, running the DHCP agent may not be required. When the SDN solution is addressing the IP assignments in another way, neutron's DHCP agent should be disabled. neutron-dhcp-agent service is scheduled to run on nodes with the label -`openstack-control-plane=enabled`. +``openstack-control-plane=enabled``. neutron-l3-agent ~~~~~~~~~~~~~~~~ @@ -190,7 +190,7 @@ If the SDN implements its own version of L3 networking, neutron-l3-agent should not be started. neutron-l3-agent service is scheduled to run on nodes with the label -`openstack-control-plane=enabled`. +``openstack-control-plane=enabled``. neutron-metadata-agent ~~~~~~~~~~~~~~~~~~~~~~ @@ -201,7 +201,7 @@ and L3 agents. Other SDNs may require to force the config driver in nova, since the metadata service is not exposed by it. neutron-metadata-agent service is scheduled to run on nodes with the label -`openstack-control-plane=enabled`. +``openstack-control-plane=enabled``. Configuring network plugin @@ -220,7 +220,7 @@ a new configuration option is added: This option will allow to configure the Neutron services in proper way, by checking what is the actual backed set in :code:`neutron/values.yaml`. -In order to meet modularity criteria of Neutron chart, section `manifests` in +In order to meet modularity criteria of Neutron chart, section ``manifests`` in :code:`neutron/values.yaml` contains boolean values describing which Neutron's Kubernetes resources should be deployed: @@ -266,7 +266,7 @@ networking functionality that SDN is providing. OpenVSwitch ~~~~~~~~~~~ The ovs set of daemonsets are running on the node labeled -`openvswitch=enabled`. This includes the compute and controller/network nodes. +``openvswitch=enabled``. This includes the compute and controller/network nodes. For more flexibility, OpenVSwitch as a tool was split out of Neutron chart, and put in separate chart dedicated OpenVSwitch. Neutron OVS agent remains in Neutron chart. Splitting out the OpenVSwitch creates possibilities to use it @@ -277,8 +277,8 @@ neutron-ovs-agent As part of Neutron chart, this daemonset is running Neutron OVS agent. It is dependent on having :code:`openvswitch-db` and :code:`openvswitch-vswitchd` deployed and ready. Since its the default choice of the networking backend, -all configuration is in place in `neutron/values.yaml`. :code:`neutron-ovs-agent` -should not be deployed when another SDN is used in `network.backend`. +all configuration is in place in ``neutron/values.yaml``. :code:`neutron-ovs-agent` +should not be deployed when another SDN is used in ``network.backend``. Script in :code:`neutron/templates/bin/_neutron-openvswitch-agent-init.sh.tpl` is responsible for determining the tunnel interface and its IP for later usage @@ -287,7 +287,7 @@ init container and main container with :code:`neutron-ovs-agent` via file :code:`/tmp/pod-shared/ml2-local-ip.ini`. Configuration of OVS bridges can be done via -`neutron/templates/bin/_neutron-openvswitch-agent-init.sh.tpl`. The +``neutron/templates/bin/_neutron-openvswitch-agent-init.sh.tpl``. The script is configuring the external network bridge and sets up any bridge mappings defined in :code:`conf.auto_bridge_add`. These values should align with @@ -314,7 +314,7 @@ than the default loopback mechanism. Linuxbridge ~~~~~~~~~~~ Linuxbridge is the second type of Neutron reference architecture L2 agent. -It is running on nodes labeled `linuxbridge=enabled`. As mentioned before, +It is running on nodes labeled ``linuxbridge=enabled``. As mentioned before, all nodes that are requiring the L2 services need to be labeled with linuxbridge. This includes both the compute and controller/network nodes. It is not possible to label the same node with both openvswitch and linuxbridge (or any other @@ -333,8 +333,8 @@ using file :code:`/tmp/pod-shared/ml2-local-ip.ini` with main linuxbridge container. In order to use linuxbridge in your OpenStack-Helm deployment, you need to -label the compute and controller/network nodes with `linuxbridge=enabled` -and use this `neutron/values.yaml` override: +label the compute and controller/network nodes with ``linuxbridge=enabled`` +and use this ``neutron/values.yaml`` override: .. code-block:: yaml diff --git a/doc/source/specs/2025.1/chart_versioning.rst b/doc/source/specs/2025.1/chart_versioning.rst index 5cfd3d297c..f36ca1248b 100644 --- a/doc/source/specs/2025.1/chart_versioning.rst +++ b/doc/source/specs/2025.1/chart_versioning.rst @@ -14,14 +14,14 @@ There are issues: chart tarball remains unchanged. * We use `chart-testing`_ to lint the charts. The chart-testing tool requires that the chart version is bumped every time any file in the - chart directory is changed. In every chart, we have a `values_overrides` + chart directory is changed. In every chart, we have a ``values_overrides`` directory where we store the version-specific overrides as well as example overrides for some specific configurations. These overrides are not part of the chart tarball, but when they are changed, we bump the chart version. -* We use `apiVersion: v1` in `Chart.yaml`, and dependencies are stored in a - separate `requirements.yaml` file. However, `apiVersion: v2` allows defining - dependencies directly in the `Chart.yaml` file. +* We use ``apiVersion: v1`` in ``Chart.yaml``, and dependencies are stored in a + separate ``requirements.yaml`` file. However, ``apiVersion: v2`` allows defining + dependencies directly in the ``Chart.yaml`` file. * We track the release notes in a separate directory and we don't have a CHANGELOG.md file in chart tarballs. * Chart maintainers are assumed to update the same release notes file @@ -39,10 +39,10 @@ Proposed Change We propose to do the following: * Move values overrides to a separate directory. -* Use `apiVersion: v2` in `Chart.yaml`. +* Use ``apiVersion: v2`` in ``Chart.yaml``. * Move release notes to the CHANGELOG.md files. * Once the Openstack is released we will bump the version of all charts to - this new release, for example `2025.1.0`. + this new release, for example ``2025.1.0``. Semver assumes the following: * MAJOR version when you make incompatible API changes @@ -59,13 +59,13 @@ We propose to do the following: Instead, we will increment the PATCH automatically when building the tarball. The PATCH will be calculated as the number of commits related to a given chart after the latest git tag. - So for example if the latest tag is `2024.2.0` and we have 3 commits + So for example if the latest tag is ``2024.2.0`` and we have 3 commits in the nova chart after this tag, the version of the nova tarball will be - `2024.2.3`. + ``2024.2.3``. All the tarballs will be published with the build metadata showing the commit SHA sum with which the tarball is built. The tarball - version will look like `2025.1.X+_`. + version will look like ``2025.1.X+_``. Implementation ============== @@ -84,23 +84,23 @@ implemented. Values overrides ~~~~~~~~~~~~~~~~ -Move values_overrides from all charts to a separate directory `values` -with the hierarchy `values_overrides//_.yaml`. +Move values_overrides from all charts to a separate directory ``values`` +with the hierarchy ``values_overrides//_.yaml``. The Openstack-Helm plugin is able to lookup the overrides in an arbitrary directory, but the directory structure must be as described above. -Update the version of all charts to `2024.2.0` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -All the charts must be updated to the version `2024.2.0` in a single commit. +Update the version of all charts to ``2024.2.0`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +All the charts must be updated to the version ``2024.2.0`` in a single commit. While developing the charts we will not change the version of the charts in their Chart.yaml files in the git repo. So, in the git repos the versions -of all charts will be the same, e.g. `2024.2.0`. It will be changed +of all charts will be the same, e.g. ``2024.2.0``. It will be changed twice a year when the Openstack is released and the version update commit will be tagged appropriately. However when we build a chart the tarball version will be updated every time. The tarball version will be calculated automatically -`2024.2.X+_` where `X` is the number +``2024.2.X+_`` where ``X`` is the number of commits related to the chart after the latest tag. .. code-block:: bash @@ -113,20 +113,20 @@ of commits related to the chart after the latest tag. .. note:: When the chart itself is not changed but is re-built with the new version of the helm-toolkit, the PATCH will not be changed and the tarball will - be published with the same version but with the new build metadata (`${OSH_INFRA_COMMIT_SHA}`). + be published with the same version but with the new build metadata (``${OSH_INFRA_COMMIT_SHA}``). Set git tag for the Openstack-Helm repositories ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We will set the git tag `2024.2.0` for all the Openstack-Helm repositories. +We will set the git tag ``2024.2.0`` for all the Openstack-Helm repositories. These tags are set by means of submitting a patch to the openstack/releases repository. Since that we will set such tag twice a year when the Openstack is released. -Update `apiVersion` in `Chart.yaml` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Update `apiVersion` to `v2` in all `Chart.yaml` files and -migrate the dependecies (helm-toolkit) from `requirements.yaml` -to `Chart.yaml`. +Update ``apiVersion`` in ``Chart.yaml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Update ``apiVersion`` to ``v2`` in all ``Chart.yaml`` files and +migrate the dependecies (helm-toolkit) from ``requirements.yaml`` +to ``Chart.yaml``. Reorganize the process of managing release notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -136,19 +136,19 @@ It generates the release notes report using the git history. We suggest the following workflow: -* When a chart is updated, the maintainer runs the `reno new ` command to create - a new release note file `releasenotes/notes/-.yaml`. +* When a chart is updated, the maintainer runs the ``reno new `` command to create + a new release note file ``releasenotes/notes/-.yaml``. * The maintainer fills in the new release note file with the necessary information. * The maintainer commits the release note file. -* While building the tarball we will use `reno report` command with a custom script +* While building the tarball we will use ``reno report`` command with a custom script to generate the release notes report and automatically prepare - the `/CHANGELOG.md` file. + the ``/CHANGELOG.md`` file. Since we are not going to bump the chart version when we update it, all the release notes will be bound to some git commits and we be put under the headers that correspond to git tags. -The format of the `CHANGELOG.md` file: +The format of the ``CHANGELOG.md`` file: .. code-block:: markdown @@ -161,12 +161,12 @@ The format of the `CHANGELOG.md` file: - Some update - Previous update -Where `X.Y.Z` is the tag in the git repository and the `X.Y.Z` section contains -all the release notes made before the tag was set. The `X.Y.Z-` +Where ``X.Y.Z`` is the tag in the git repository and the ``X.Y.Z`` section contains +all the release notes made before the tag was set. The ``X.Y.Z-`` section contains all the release notes made after the tag was set. -At this point we have the only tag `0.1.0`. So, when we set the `2024.2.0` tag almost all -the release notes will go to this tag and the `CHANGELOG.md` file. So it will look like: +At this point we have the only tag ``0.1.0``. So, when we set the ``2024.2.0`` tag almost all +the release notes will go to this tag and the ``CHANGELOG.md`` file. So it will look like: .. code-block:: markdown @@ -185,7 +185,7 @@ Update the versioning policy we will re-build it and publish with the new version according to how it is described above. All other charts also will be re-built with this new version of - helm-toolkit (inside) and published with the new build metadata (new `$OSH_INFRA_COMMIT_SHA`). + helm-toolkit (inside) and published with the new build metadata (new ``$OSH_INFRA_COMMIT_SHA``). Helm-toolkit version will not be pinned in the charts. * When a particular chart is changed, we will re-build and publish only this chart. So all charts will be built and published independently of each other. @@ -201,7 +201,7 @@ Documentation Impact The user documentation must be updated and it must be emphasized that the chart version is not equal to the Openstack release version and that the Openstack version is defined by the images used with the charts. Also it must be explained that a particular version -like `2024.2.X` is compatible with those Openstack releases that were maintained at the time -`2024.2.X` was built and published (i.e `2023.1`, `2023.2`, `2024.1`, `2024.2`). +like ``2024.2.X`` is compatible with those Openstack releases that were maintained at the time +``2024.2.X`` was built and published (i.e ``2023.1``, ``2023.2``, ``2024.1``, ``2024.2``). .. _chart-testing: https://github.com/helm/chart-testing.git diff --git a/doc/source/specs/2025.2/own_service_accounts.rst b/doc/source/specs/2025.2/own_service_accounts.rst index d093889ce5..e8db1c9a73 100644 --- a/doc/source/specs/2025.2/own_service_accounts.rst +++ b/doc/source/specs/2025.2/own_service_accounts.rst @@ -8,9 +8,9 @@ Problem Description Currently when an OpenStack-Helm chart deploys a OpenStack service, it creates a service account that is used by other Openstack services to interact with the service's API. For example, the Nova -chart creates a service account called `nova` and other charts +chart creates a service account called ``nova`` and other charts like Cinder and Neutron configure Cinder and Neutron services -to use the `nova` service account to interact with the Nova API. +to use the ``nova`` service account to interact with the Nova API. However, there might be scenarios where multiple Nova accounts are necessary. For instance, if Neutron requires more permissive @@ -39,13 +39,13 @@ E.g. the Neutron chart will create the following service accounts: * neutron (used by Neutron to communicate with the Keystone API to check auth tokens and other services can use it to get access to the Neutron API) * neutron_nova (used by Neutron to get access to the Nova API instead - of using `nova` service account created by the Nova chart) + of using ``nova`` service account created by the Nova chart) * neutron_placement (used by Neutron to get access to the Placement API - instead of using `placement` service account managed by the Placement chart) + instead of using ``placement`` service account managed by the Placement chart) The proposed change is going to be backward compatible because the Neutron -chart will still be able to use the `neutron` and `placement` service accounts -managed by the Nova and Placement charts. Also the `neutron` service account +chart will still be able to use the ``neutron`` and ``placement`` service accounts +managed by the Nova and Placement charts. Also the ``neutron`` service account can still be used by other charts to communicate with the Neutron API. Implementation @@ -60,15 +60,15 @@ Primary assignee: Values ------ -Service accounts credentials are defined in the `values.yaml` files -in the `.Values.endpoints.identity.auth` section. The section contains +Service accounts credentials are defined in the ``values.yaml`` files +in the ``.Values.endpoints.identity.auth`` section. The section contains a bunch of dicts defining credentials for every service account. Currently those dicts which correspond to service accounts managed by other charts must be aligned with those charts values. For example, the Neutron values must -define the `nova` service account the same way as the Nova chart does. +define the ``nova`` service account the same way as the Nova chart does. -The following is the example of how the `.Values.endpoints.identity.auth` +The following is the example of how the ``.Values.endpoints.identity.auth`` section of a chart must be modified. The example is given for the Neutron chart: .. code-block:: yaml @@ -103,7 +103,7 @@ section of a chart must be modified. The example is given for the Neutron chart: # Service account with the following username/password # will be created by the Keystone user job # and will be used for Neutron configuration. Also the - # `role` field must be added to assign necessary roles + # ``role`` field must be added to assign necessary roles # to the service account. nova: role: admin,service @@ -116,7 +116,7 @@ section of a chart must be modified. The example is given for the Neutron chart: # Service account with the following username/password # will be created by the Keystone user job # and will be used for Neutron configuration. Also the - # `role` field must be added to assign necessary roles + # ``role`` field must be added to assign necessary roles # to the service account. placement: role: admin,service @@ -135,23 +135,23 @@ used by the `Keystone user manifest`_ to create the service accounts. So the the template that deploys those secrets must be updated to create the secrets for all service accounts defined in the -`.Values.endpoints.identity.auth` section. +``.Values.endpoints.identity.auth`` section. -Also the `.Values.secrets.identity` section must be updated and +Also the ``.Values.secrets.identity`` section must be updated and secret names must be added for all service accounts defined in the -`.Values.endpoints.identity.auth` section. +``.Values.endpoints.identity.auth`` section. Keystone user manifest ---------------------- -The Helm-toolkit chart defines the `Keystone user manifest`_ +The Helm-toolkit chart defines the ``Keystone user manifest``_ which is used by all Openstack charts to create service accounts. -The manifest must be updated to be able to accept `serviceUsers` parameter +The manifest must be updated to be able to accept ``serviceUsers`` parameter which will be the list of service accounts to be created by the job. -For backward compatibility if the `serviceUsers` parameter is not given -then the manifest will use the `serviceUser` parameter or `serviceName` parameter -to define the `serviceUsers` as a list with a single element. +For backward compatibility if the ``serviceUsers`` parameter is not given +then the manifest will use the ``serviceUser`` parameter or ``serviceName`` parameter +to define the ``serviceUsers`` as a list with a single element. .. code-block:: diff --git a/doc/source/specs/multi-os.rst b/doc/source/specs/multi-os.rst index 3b53d78fc5..3d9e9e6de7 100644 --- a/doc/source/specs/multi-os.rst +++ b/doc/source/specs/multi-os.rst @@ -194,10 +194,10 @@ No change in testing is required, *per se*. It is expected the new software configuration would be tested with the current practices. -On top of that, the newly provided `example_values/` must +On top of that, the newly provided ``example_values/`` must aim for being tested **as soon as possible upon delivery**. Without tests, those examples will decrepit. The changes in CI pipelines for making use -of `example_values` is outside the scope of this spec. +of ``example_values`` is outside the scope of this spec. Documentation Impact ==================== diff --git a/doc/source/specs/osh-1.0-requirements.rst b/doc/source/specs/osh-1.0-requirements.rst index 174d87bd48..1afea38ca2 100644 --- a/doc/source/specs/osh-1.0-requirements.rst +++ b/doc/source/specs/osh-1.0-requirements.rst @@ -113,9 +113,9 @@ in Helm-Toolkit. The following manifests have yet to be combined: **Standardization of values** OpenStack-Helm has developed a number of conventions around the format and -ordering of charts' `values.yaml` file, in support of both reusable Helm-Toolkit +ordering of charts' ``values.yaml`` file, in support of both reusable Helm-Toolkit functions and ease of developer ramp-up. For 1.0 readiness, OpenStack-Helm must -cement these conventions within a spec, as well as the ordering of `values.yaml` +cement these conventions within a spec, as well as the ordering of ``values.yaml`` keys. These conventions must then be gated to guarantee conformity. The spec in progress can be found here [1]_. @@ -137,9 +137,9 @@ in-place upgradability. In order to maximize flexibility for operators, and to help facilitate upgrades to newer versions of containerized software without editing the chart itself, all configuration files will be specified dynamically -based on `values.yaml` and overrides. In most cases the config files +based on ``values.yaml`` and overrides. In most cases the config files will be generated based on the YAML values tree itself, and in some -cases the config file content will be specified in `values.yaml` as a +cases the config file content will be specified in ``values.yaml`` as a string literal. Documentation @@ -184,7 +184,7 @@ Release notes for the 1.0 release must be prepared, following OpenStack best practices. The criteria for future changes that should be included in release notes in an ongoing fashion must be defined / documented as well. -- `values.yaml` changes +- ``values.yaml`` changes - New charts - Any other changes to the external interface of OpenStack-Helm @@ -236,7 +236,7 @@ Primary assignee: - mattmceuen (Matt McEuen ) for coordination - powerds (DaeSeong Kim ) for the - `values.yaml` ordering spec [1]_ + ``values.yaml`` ordering spec [1]_ - portdirect (Pete Birley ) for the release management spec [2]_ - randeep.jalli (Randeep Jalli ) and diff --git a/doc/source/testing/ceph-upgrade.rst b/doc/source/testing/ceph-upgrade.rst index da84798f7a..2251e03de7 100644 --- a/doc/source/testing/ceph-upgrade.rst +++ b/doc/source/testing/ceph-upgrade.rst @@ -68,9 +68,9 @@ Steps: tee /tmp/ceph.yaml << EOF ... - network: - public: ${CEPH_PUBLIC_NETWORK} - cluster: ${CEPH_CLUSTER_NETWORK} + network: + public: ${CEPH_PUBLIC_NETWORK} + cluster: ${CEPH_CLUSTER_NETWORK} images: tags: ceph_bootstrap: 'docker.io/ceph/daemon:master-0351083-luminous-ubuntu-16.04-x86_64' @@ -84,19 +84,19 @@ Steps: ceph_rgw: 'docker.io/ceph/daemon:master-0351083-luminous-ubuntu-16.04-x86_64' ceph_cephfs_provisioner: 'quay.io/external_storage/cephfs-provisioner:v0.1.1' ceph_rbd_provisioner: 'quay.io/external_storage/rbd-provisioner:v0.1.0' - conf: - ceph: - global: - fsid: ${CEPH_FS_ID} - rgw_ks: - enabled: true - pool: - crush: - tunables: ${CRUSH_TUNABLES} - target: + conf: + ceph: + global: + fsid: ${CEPH_FS_ID} + rgw_ks: + enabled: true + pool: + crush: + tunables: ${CRUSH_TUNABLES} + target: # NOTE(portdirect): 5 nodes, with one osd per node - osd: 5 - pg_per_osd: 100 + osd: 5 + pg_per_osd: 100 ... EOF diff --git a/doc/source/troubleshooting/persistent-storage.rst b/doc/source/troubleshooting/persistent-storage.rst index 7d89e87882..9c41cc03ca 100644 --- a/doc/source/troubleshooting/persistent-storage.rst +++ b/doc/source/troubleshooting/persistent-storage.rst @@ -40,7 +40,7 @@ can be done with the following Ceph command: admin@kubenode01:~$ Use one of your Ceph Monitors to check the status of the cluster. A -couple of things to note above; our health is `HEALTH\_OK`, we have 3 +couple of things to note above; our health is ``HEALTH_OK``, we have 3 mons, we've established a quorum, and we can see that all of our OSDs are up and in the OSD map.