Merge "Fix: Update outdated documentation"

39 files changed, 130 insertions, 127 deletions

diff --git a/doc/source/admin/acme.rst b/doc/source/admin/acme.rst
index 6a12efe11..2955c9f3a 100644
--- a/doc/source/admin/acme.rst
+++ b/doc/source/admin/acme.rst
@@ -26,7 +26,7 @@ is ``192.168.1.1``, the config would look like the following:
 
 .. code-block:: yaml
 
-  enable_horizon: "yes"
+  enable_horizon: true
   acme_client_servers:
     - server certbot 192.168.1.1:80
 
diff --git a/doc/source/admin/advanced-configuration.rst b/doc/source/admin/advanced-configuration.rst
index 579dd11ca..7ece68e3a 100644
--- a/doc/source/admin/advanced-configuration.rst
+++ b/doc/source/admin/advanced-configuration.rst
@@ -216,7 +216,7 @@ adding:
 
 .. code-block:: yaml
 
-   enable_haproxy: "no"
+   enable_haproxy: false
 
 Note this method is not recommended and generally not tested by the
 Kolla community, but included since sometimes a free IP is not available
@@ -233,7 +233,7 @@ first disable the deployment of the central logging.
 
 .. code-block:: yaml
 
-   enable_central_logging: "no"
+   enable_central_logging: false
 
 Now you can use the parameter ``elasticsearch_address`` to configure the
 address of the external Elasticsearch environment.
diff --git a/doc/source/admin/mariadb-backup-and-restore.rst b/doc/source/admin/mariadb-backup-and-restore.rst
index 596b7f952..f6e77fe4b 100644
--- a/doc/source/admin/mariadb-backup-and-restore.rst
+++ b/doc/source/admin/mariadb-backup-and-restore.rst
@@ -27,7 +27,7 @@ Firstly, enable backups via ``globals.yml``:
 
 .. code-block:: console
 
-   enable_mariabackup: "yes"
+   enable_mariabackup: true
 
 Then, kick off a reconfiguration of MariaDB:
 
diff --git a/doc/source/admin/tls.rst b/doc/source/admin/tls.rst
index 3183c45e8..a78f4c599 100644
--- a/doc/source/admin/tls.rst
+++ b/doc/source/admin/tls.rst
@@ -48,10 +48,10 @@ APIs, configure the following in ``globals.yml``:
 
 .. code-block:: yaml
 
-  kolla_enable_tls_internal: "yes"
-  kolla_enable_tls_external: "yes"
-  kolla_enable_tls_backend: "yes"
-  kolla_copy_ca_into_containers: "yes"
+  kolla_enable_tls_internal: true
+  kolla_enable_tls_external: true
+  kolla_enable_tls_backend: true
+  kolla_copy_ca_into_containers: true
 
 If deploying on Debian or Ubuntu:
 
@@ -100,13 +100,13 @@ encryption:
 
 .. code-block:: yaml
 
-  kolla_enable_tls_external: "yes"
+  kolla_enable_tls_external: true
 
 To enable internal TLS encryption:
 
 .. code-block:: yaml
 
-  kolla_enable_tls_internal: "yes"
+  kolla_enable_tls_internal: true
 
 Two certificate files are required to use TLS securely with authentication,
 which will be provided by your Certificate Authority:
@@ -218,8 +218,18 @@ Enabling TLS on the backend services secures communication between the
 HAProxy listing on the internal/external VIP and the OpenStack
 services. It also enables secure end-to-end communication between OpenStack
 services that support TLS termination. The OpenStack services that support
-backend TLS termination in Victoria are: Nova, Ironic, Neutron, Keystone,
-Glance, Heat, Placement, Horizon, Barbican, and Cinder.
+backend TLS termination are:
+
+* Barbican
+* Cinder
+* Glance
+* Heat
+* Horizon
+* Ironic
+* Keystone
+* Neutron
+* Nova
+* Placement
 
 The configuration variables that control back-end TLS for service endpoints
 are:
@@ -235,11 +245,11 @@ communication:
 
 .. code-block:: yaml
 
-  kolla_enable_tls_backend: "yes"
+  kolla_enable_tls_backend: true
 
 It is also possible to enable back-end TLS on a per-service basis. For example,
 to enable back-end TLS for Keystone, set ``keystone_enable_tls_backend`` to
-``yes``.
+``true``.
 
 The default values for ``haproxy_backend_cacert`` and
 ``haproxy_backend_cacert_dir`` should suffice if the certificate is in the
@@ -284,7 +294,7 @@ disable verification of the backend certificate:
 
 .. code-block:: yaml
 
-  kolla_verify_tls_backend: "no"
+  kolla_verify_tls_backend: false
 
 Generating TLS certificates with Let's Encrypt
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -297,7 +307,7 @@ must be configured in ``globals.yml``:
 
 .. code-block:: yaml
 
-  enable_letsencrypt: "yes"
+  enable_letsencrypt: true
   letsencrypt_email: "<The email used for registration and recovery contact>"
 
 The Let's Encrypt container will attempt to renew your certificates every 12
diff --git a/doc/source/reference/bare-metal/ironic-guide.rst b/doc/source/reference/bare-metal/ironic-guide.rst
index 962ece762..75c3865f2 100644
--- a/doc/source/reference/bare-metal/ironic-guide.rst
+++ b/doc/source/reference/bare-metal/ironic-guide.rst
@@ -16,7 +16,7 @@ Enable Ironic in ``/etc/kolla/globals.yml``:
 
 .. code-block:: yaml
 
-   enable_ironic: "yes"
+   enable_ironic: true
 
 In the same file, define a network interface as the default NIC for dnsmasq and
 define a network to be used for the Ironic cleaning network:
@@ -125,7 +125,7 @@ PXE filter service:
 
 .. code-block:: yaml
 
-   enable_ironic_pxe_filter: "yes"
+   enable_ironic_pxe_filter: true
 
 The PXE filter container runs alongside ``ironic-dnsmasq`` and cleans up stale
 DHCP entries. It is especially useful when auto discovery is enabled and when
@@ -189,20 +189,20 @@ keystone could be installed in one region (let's say region 1) and ironic -
 in another region (let's say region 2). In this case we don't install keystone
 together with ironic in region 2, but have to configure ironic to connect to
 existing keystone in region 1. To deploy ironic in this way we have to set
-variable ``enable_keystone`` to ``"no"``.
+variable ``enable_keystone`` to ``false``.
 
 .. code-block:: yaml
 
-    enable_keystone: "no"
+    enable_keystone: false
 
 It will prevent keystone from being installed in region 2.
 
 To add keystone-related sections in ironic.conf, it is also needed to set
-variable ``ironic_enable_keystone_integration`` to ``"yes"``
+variable ``ironic_enable_keystone_integration`` to ``true``
 
 .. code-block:: yaml
 
-    ironic_enable_keystone_integration: "yes"
+    ironic_enable_keystone_integration: true
 
 Avoiding problems with high availability
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/source/reference/compute/nova-cells-guide.rst b/doc/source/reference/compute/nova-cells-guide.rst
index a808bc083..616ba0a5f 100644
--- a/doc/source/reference/compute/nova-cells-guide.rst
+++ b/doc/source/reference/compute/nova-cells-guide.rst
@@ -170,7 +170,7 @@ Support for deployment of multiple cells is disabled by default - nova is
 deployed in single conductor mode.
 
 Deployment of multiple cells may be enabled by setting ``enable_cells`` to
-``yes`` in ``globals.yml``. This deploys nova in superconductor mode, with
+``true`` in ``globals.yml``. This deploys nova in superconductor mode, with
 separate conductors for each cell.
 
 Naming cells
diff --git a/doc/source/reference/compute/nova-fake-driver.rst b/doc/source/reference/compute/nova-fake-driver.rst
index df003f8f4..bef4d1781 100644
--- a/doc/source/reference/compute/nova-fake-driver.rst
+++ b/doc/source/reference/compute/nova-fake-driver.rst
@@ -29,7 +29,7 @@ the command line options.
 
 .. code-block:: yaml
 
-   enable_nova_fake: "yes"
+   enable_nova_fake: true
    num_nova_fake_per_node: 5
 
 Each Compute node will run 5 ``nova-compute`` containers and 5
diff --git a/doc/source/reference/compute/nova-guide.rst b/doc/source/reference/compute/nova-guide.rst
index 87757f930..1069030bb 100644
--- a/doc/source/reference/compute/nova-guide.rst
+++ b/doc/source/reference/compute/nova-guide.rst
@@ -7,7 +7,7 @@ this is via Virtual Machines (VMs), but may also be via bare metal servers if
 Nova is coupled with Ironic.
 
 Nova is enabled by default, but may be disabled by setting ``enable_nova`` to
-``no`` in ``globals.yml``.
+``false`` in ``globals.yml``.
 
 Virtualisation Drivers
 ======================
@@ -43,7 +43,7 @@ Consoles
 The console driver may be selected via ``nova_console`` in ``globals.yml``.
 Valid options are ``none``, ``novnc`` and ``spice``. Additionally,
 serial console support can be enabled by setting
-``enable_nova_serialconsole_proxy`` to ``yes``.
+``enable_nova_serialconsole_proxy`` to ``true``.
 
 ``spice`` consoles have additional configuration options used by Kolla Ansible:
 
diff --git a/doc/source/reference/compute/zun-guide.rst b/doc/source/reference/compute/zun-guide.rst
index 9959dede1..8df209a73 100644
--- a/doc/source/reference/compute/zun-guide.rst
+++ b/doc/source/reference/compute/zun-guide.rst
@@ -17,11 +17,11 @@ following variables:
 
 .. code-block:: yaml
 
-   enable_zun: "yes"
-   enable_kuryr: "yes"
-   enable_etcd: "yes"
-   docker_configure_for_zun: "yes"
-   containerd_configure_for_zun: "yes"
+   enable_zun: true
+   enable_kuryr: true
+   enable_etcd: true
+   docker_configure_for_zun: true
+   containerd_configure_for_zun: true
 
 Docker reconfiguration requires rebootstrapping before deploy.
 Make sure you understand the consequences of restarting Docker.
diff --git a/doc/source/reference/containers/kuryr-guide.rst b/doc/source/reference/containers/kuryr-guide.rst
index f748d16c5..f85451d57 100644
--- a/doc/source/reference/containers/kuryr-guide.rst
+++ b/doc/source/reference/containers/kuryr-guide.rst
@@ -33,8 +33,8 @@ following variables
 
 .. code-block:: yaml
 
-   enable_etcd: "yes"
-   enable_kuryr: "yes"
+   enable_etcd: true
+   enable_kuryr: true
 
 Deploy the OpenStack cloud and kuryr network plugin
 
diff --git a/doc/source/reference/databases/external-mariadb-guide.rst b/doc/source/reference/databases/external-mariadb-guide.rst
index 90b5f7908..55cba4c2b 100644
--- a/doc/source/reference/databases/external-mariadb-guide.rst
+++ b/doc/source/reference/databases/external-mariadb-guide.rst
@@ -31,7 +31,7 @@ by ensuring the following line exists within ``/etc/kolla/globals.yml`` :
 
 .. code-block:: yaml
 
-   enable_mariadb: "no"
+   enable_mariadb: false
 
 There are two ways in which you can use external MariaDB:
 * Using an already load-balanced MariaDB address
@@ -60,7 +60,7 @@ need to do the following:
 
 .. note::
 
-   If ``enable_external_mariadb_load_balancer`` is set to ``no``
+   If ``enable_external_mariadb_load_balancer`` is set to ``false``
    (default), the external DB load balancer should be accessible
    from all nodes during your deployment.
 
@@ -87,7 +87,7 @@ according to the following configuration:
 
 .. code-block:: yaml
 
-   enable_external_mariadb_load_balancer: yes
+   enable_external_mariadb_load_balancer: true
 
 Using External MariaDB with a privileged user
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/source/reference/high-availability/haproxy-guide.rst b/doc/source/reference/high-availability/haproxy-guide.rst
index 0d1219789..02e09158b 100644
--- a/doc/source/reference/high-availability/haproxy-guide.rst
+++ b/doc/source/reference/high-availability/haproxy-guide.rst
@@ -19,8 +19,8 @@ setting the following in ``/etc/kolla/globals.yml``:
 
 .. code-block:: yaml
 
-   enable_haproxy: "no"
-   enable_keepalived: "no"
+   enable_haproxy: false
+   enable_keepalived: false
 
 Single external frontend for services
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -91,7 +91,7 @@ disabled by setting the following in ``/etc/kolla/globals.yml``:
 
 .. code-block:: yaml
 
-   haproxy_enable_http2: "no"
+   haproxy_enable_http2: false
 
 SSL/TLS Settings
 ----------------
diff --git a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
index f9b96697d..870be297f 100644
--- a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
@@ -16,7 +16,7 @@ the following:
 
 .. code-block:: yaml
 
-   enable_central_logging: "yes"
+   enable_central_logging: true
 
 OpenSearch
 ~~~~~~~~~~
diff --git a/doc/source/reference/logging-and-monitoring/grafana-guide.rst b/doc/source/reference/logging-and-monitoring/grafana-guide.rst
index 6f89c2016..412ca88e1 100644
--- a/doc/source/reference/logging-and-monitoring/grafana-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/grafana-guide.rst
@@ -20,13 +20,13 @@ and change the following:
 
 .. code-block:: yaml
 
-   enable_grafana: "yes"
+   enable_grafana: true
 
 If you would like to set up Prometheus as a data source, additionally set:
 
 .. code-block:: yaml
 
-   enable_prometheus: "yes"
+   enable_prometheus: true
 
 Please follow :doc:`Prometheus Guide <prometheus-guide>` for more information.
 
diff --git a/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst b/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst
index 9951d4472..fd56f65dc 100644
--- a/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/osprofiler-guide.rst
@@ -22,8 +22,8 @@ Enable ``OSprofiler`` in ``/etc/kolla/globals.yml`` file:
 
 .. code-block:: yaml
 
-   enable_osprofiler: "yes"
-   enable_elasticsearch: "yes"
+   enable_osprofiler: true
+   enable_elasticsearch: true
 
 Verify operation
 ----------------
diff --git a/doc/source/reference/logging-and-monitoring/prometheus-guide.rst b/doc/source/reference/logging-and-monitoring/prometheus-guide.rst
index d1e4109fc..0680099a3 100644
--- a/doc/source/reference/logging-and-monitoring/prometheus-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/prometheus-guide.rst
@@ -18,13 +18,13 @@ and change the following:
 
 .. code-block:: yaml
 
-   enable_prometheus: "yes"
+   enable_prometheus: true
 
 Note: This will deploy Prometheus version 2.x. Any potentially existing
 Prometheus 1.x instances deployed by previous Kolla Ansible releases will
 conflict with current version and should be manually stopped and/or removed.
 If you would like to stay with version 1.x, set the ``enable_prometheus``
-variable to ``no``.
+variable to ``false``.
 
 In order to remove leftover volume containing Prometheus 1.x data, execute:
 
diff --git a/doc/source/reference/message-queues/external-rabbitmq-guide.rst b/doc/source/reference/message-queues/external-rabbitmq-guide.rst
index 10277f641..571751657 100644
--- a/doc/source/reference/message-queues/external-rabbitmq-guide.rst
+++ b/doc/source/reference/message-queues/external-rabbitmq-guide.rst
@@ -23,7 +23,7 @@ by ensuring the following line exists within ``/etc/kolla/globals.yml`` :
 
 .. code-block:: yaml
 
-   enable_rabbitmq: "no"
+   enable_rabbitmq: false
 
 
 Overwriting transport_url within ``globals.yml``
diff --git a/doc/source/reference/networking/designate-guide.rst b/doc/source/reference/networking/designate-guide.rst
index aa0932b87..a46eb4da3 100644
--- a/doc/source/reference/networking/designate-guide.rst
+++ b/doc/source/reference/networking/designate-guide.rst
@@ -23,7 +23,7 @@ Enable Designate service in ``/etc/kolla/globals.yml``
 
 .. code-block:: yaml
 
-   enable_designate: "yes"
+   enable_designate: true
    neutron_dns_domain: "example.org."
 
 .. important::
@@ -54,7 +54,7 @@ Configure Designate options in ``/etc/kolla/globals.yml``
    enable a supported coordination backend, currently only ``valkey``
    is supported. The backend choice can be overridden via the
    ``designate_coordination_backend`` variable. It defaults to ``valkey``
-   when ``valkey`` is enabled (``enable_valkey`` is set to ``yes``).
+   when ``valkey`` is enabled (``enable_valkey`` is set to ``true``).
 
 The following additional variables are required depending on which backend you
 intend to use:
@@ -108,7 +108,7 @@ to trigger record creation & deletion.
 
 .. note::
    Service ``designate-sink`` in kolla deployments is disabled by default
-   and can be enabled by ``designate_enable_notifications_sink: yes``.
+   and can be enabled by ``designate_enable_notifications_sink: true``.
 
 Create default Designate Zone for Neutron:
 
diff --git a/doc/source/reference/networking/dpdk.rst b/doc/source/reference/networking/dpdk.rst
index 478596a66..96f9e52e5 100644
--- a/doc/source/reference/networking/dpdk.rst
+++ b/doc/source/reference/networking/dpdk.rst
@@ -71,8 +71,8 @@ To enable ovs-dpdk, add the following configuration to
 .. code-block:: yaml
 
    ovs_datapath: "netdev"
-   enable_ovs_dpdk: yes
-   enable_openvswitch: yes
+   enable_ovs_dpdk: true
+   enable_openvswitch: true
    tunnel_interface: "dpdk_bridge"
    neutron_bridge_name: "dpdk_bridge"
 
diff --git a/doc/source/reference/networking/neutron-extensions.rst b/doc/source/reference/networking/neutron-extensions.rst
index 2e8be4b13..8c4834079 100644
--- a/doc/source/reference/networking/neutron-extensions.rst
+++ b/doc/source/reference/networking/neutron-extensions.rst
@@ -14,7 +14,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows:
 
 .. code-block:: yaml
 
-   enable_neutron_sfc: "yes"
+   enable_neutron_sfc: true
 
 Verification
 ------------
@@ -37,7 +37,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows:
 
 .. code-block:: yaml
 
-   enable_neutron_fwaas: "yes"
+   enable_neutron_fwaas: true
 
 For more information on FWaaS in Neutron refer to the
 :neutron-doc:`Neutron FWaaS docs <admin/fwaas.html>`.
@@ -52,7 +52,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows:
 
 .. code-block:: yaml
 
-   enable_neutron_vpnaas: "yes"
+   enable_neutron_vpnaas: true
 
 Verification
 ------------
@@ -119,7 +119,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows:
 
 .. code-block:: yaml
 
-   enable_neutron_trunk: "yes"
+   enable_neutron_trunk: true
 
 Neutron Logging Framework
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ Modify the ``/etc/kolla/globals.yml`` file as the following example shows:
 
 .. code-block:: yaml
 
-   enable_neutron_packet_logging: "yes"
+   enable_neutron_packet_logging: true
 
 For OVS deployment, you need to override the firewall driver in
 `openvswitch_agent.ini` to:
diff --git a/doc/source/reference/networking/neutron.rst b/doc/source/reference/networking/neutron.rst
index 3fec073a5..b4f7a884f 100644
--- a/doc/source/reference/networking/neutron.rst
+++ b/doc/source/reference/networking/neutron.rst
@@ -109,7 +109,7 @@ To use provider networks in instances you also need to set the following in
 
 .. code-block:: yaml
 
-   enable_neutron_provider_networks: yes
+   enable_neutron_provider_networks: true
 
 For provider networks, compute hosts must have an external bridge
 created and configured by Ansible (this is also necessary when
@@ -188,7 +188,7 @@ L3 and DHCP agents can be created in a high availability (HA) state with:
 
 .. code-block:: yaml
 
-   enable_neutron_agent_ha: "yes"
+   enable_neutron_agent_ha: true
 
 This allows networking to fail over across controllers if the active agent is
 stopped. If this option is enabled, it can be advantageous to also set:
@@ -275,7 +275,7 @@ In order to deploy Neutron OVN Agent you need to set the following:
 .. path /etc/kolla/globals.yml
 .. code-block:: yaml
 
-   neutron_enable_ovn_agent: "yes"
+   neutron_enable_ovn_agent: true
 
 Currently the agent is only needed for QoS for hardware offloaded ports.
 
@@ -306,7 +306,7 @@ set the following (assuming neutron SR-IOV agent is also enabled using
 .. path /etc/kolla/globals.yml
 .. code-block:: yaml
 
-   enable_neutron_mlnx: "yes"
+   enable_neutron_mlnx: true
 
 Additionally, you will also need to provide physnet:interface mappings
 via ``neutron_mlnx_physnet_mappings`` which is presented to
diff --git a/doc/source/reference/networking/octavia.rst b/doc/source/reference/networking/octavia.rst
index 7a29d67fa..33a64bd6c 100644
--- a/doc/source/reference/networking/octavia.rst
+++ b/doc/source/reference/networking/octavia.rst
@@ -14,7 +14,7 @@ Enable the octavia service in ``globals.yml``:
 
 .. code-block:: yaml
 
-   enable_octavia: "yes"
+   enable_octavia: true
 
 Amphora provider
 ================
@@ -96,7 +96,7 @@ networks:
 
 .. code-block:: yaml
 
-   enable_neutron_provider_networks: yes
+   enable_neutron_provider_networks: true
 
 Configure the name of the network interface on the controllers used to access
 the Octavia management network. If using a VLAN provider network, ensure that
@@ -219,7 +219,7 @@ For example:
        allocation_pool_start: "10.1.2.100"
        allocation_pool_end: "10.1.2.200"
        gateway_ip: "10.1.2.1"
-       enable_dhcp: yes
+       enable_dhcp: true
 
 Deploy Octavia with Kolla Ansible:
 
@@ -252,16 +252,6 @@ as follows:
    Ensure that you have executed ``kolla-ansible post-deploy`` and set
    ``enable_octavia`` to yes in ``global.yml``
 
-.. note::
-
-   In Train and earlier releases, resources should be registered in the
-   ``admin`` project. This is configured via ``octavia_service_auth_project``,
-   and may be set to ``service`` to avoid a breaking change when upgrading to
-   Ussuri. Changing the project on an existing system requires at a minimum
-   registering a new security group in the new project. Ideally the flavor and
-   network should be recreated in the new project, although this will impact
-   existing Amphorae.
-
 Amphora flavor
 ~~~~~~~~~~~~~~
 
diff --git a/doc/source/reference/networking/sriov.rst b/doc/source/reference/networking/sriov.rst
index 73afa7b0f..94417bfa0 100644
--- a/doc/source/reference/networking/sriov.rst
+++ b/doc/source/reference/networking/sriov.rst
@@ -21,7 +21,7 @@ shows which automatically appends ``sriovnicswitch`` to the
 .. path /etc/kolla/globals.yml
 .. code-block:: yaml
 
-   enable_neutron_sriov: "yes"
+   enable_neutron_sriov: true
 
 It is also a requirement to define physnet:interface mappings for all
 SRIOV devices as shown in the following example where ``sriovtenant1`` is the
diff --git a/doc/source/reference/orchestration-and-nfv/tacker-guide.rst b/doc/source/reference/orchestration-and-nfv/tacker-guide.rst
index 4c99e72e1..95e82031e 100644
--- a/doc/source/reference/orchestration-and-nfv/tacker-guide.rst
+++ b/doc/source/reference/orchestration-and-nfv/tacker-guide.rst
@@ -40,8 +40,8 @@ In order to enable them, you need to edit the file
 
 .. code-block:: yaml
 
-   enable_tacker: "yes"
-   enable_barbican: "yes"
+   enable_tacker: true
+   enable_barbican: true
 
 .. warning::
 
diff --git a/doc/source/reference/shared-services/glance-guide.rst b/doc/source/reference/shared-services/glance-guide.rst
index 082bd40c6..d8e73e44d 100644
--- a/doc/source/reference/shared-services/glance-guide.rst
+++ b/doc/source/reference/shared-services/glance-guide.rst
@@ -99,7 +99,7 @@ need to be enabled.
 
 .. code-block:: yaml
 
-   glance_enable_rolling_upgrade: "yes"
+   glance_enable_rolling_upgrade: true
 
 .. warning::
 
@@ -118,7 +118,7 @@ It is the default mode, ensure rolling upgrade method is not enabled.
 
 .. code-block:: yaml
 
-   glance_enable_rolling_upgrade: "no"
+   glance_enable_rolling_upgrade: false
 
 
 Other configuration
@@ -131,7 +131,7 @@ Glance cache is disabled by default, it can be enabled by:
 
 .. code-block:: yaml
 
-   enable_glance_image_cache: "yes"
+   enable_glance_image_cache: true
    glance_cache_max_size: "10737418240" # 10GB by default
 
 .. warning::
@@ -154,7 +154,7 @@ is disabled by default, it can be enabled by:
 
 .. code-block:: yaml
 
-   glance_enable_property_protection: "yes"
+   glance_enable_property_protection: true
 
 
 and defining ``property-protections-rules.conf`` under
@@ -170,7 +170,7 @@ is disabled by default, it can be enabled by:
 
 .. code-block:: yaml
 
-  glance_enable_interoperable_image_import: "yes"
+  glance_enable_interoperable_image_import: true
 
 and defining ``glance-image-import.conf`` under
 ``{{ node_custom_config }}/glance/``.
diff --git a/doc/source/reference/shared-services/skyline-guide.rst b/doc/source/reference/shared-services/skyline-guide.rst
index fb735c997..4aea2beb7 100644
--- a/doc/source/reference/shared-services/skyline-guide.rst
+++ b/doc/source/reference/shared-services/skyline-guide.rst
@@ -12,18 +12,18 @@ Single Sign On (SSO)
 Skyline supports SSO with an Openid IdP. When you configure an IdP with
 protocol openid, Kolla will automatically enable SSO and set up the trusted
 dashboard url for Keystone. If you don't want to use SSO in Skyline, you can
-disable it by setting ``skyline_enable_sso`` to "no":
+disable it by setting ``skyline_enable_sso`` to ``false``:
 
 .. code-block:: yaml
 
-   skyline_enable_sso: "no"
+   skyline_enable_sso: false
 
 If you want to enable it without setting up the IdP with Kolla you can simply
 enable it with:
 
 .. code-block:: yaml
 
-   skyline_enable_sso: "yes"
+   skyline_enable_sso: true
 
 Customize logos
 ~~~~~~~~~~~~~~~
diff --git a/doc/source/reference/storage/cinder-guide-lightbits.rst b/doc/source/reference/storage/cinder-guide-lightbits.rst
index b09d0e4a1..dc1ea7ec0 100644
--- a/doc/source/reference/storage/cinder-guide-lightbits.rst
+++ b/doc/source/reference/storage/cinder-guide-lightbits.rst
@@ -13,7 +13,7 @@ configure the ``Lightbits labs`` Cinder driver in
 
 .. code-block:: yaml
 
-  enable_cinder_backend_lightbits: "yes"
+  enable_cinder_backend_lightbits: true
 
 .. end
 
diff --git a/doc/source/reference/storage/cinder-guide-pure.rst b/doc/source/reference/storage/cinder-guide-pure.rst
index 0970d98ea..c26104761 100644
--- a/doc/source/reference/storage/cinder-guide-pure.rst
+++ b/doc/source/reference/storage/cinder-guide-pure.rst
@@ -12,7 +12,7 @@ configure the ``FlashArray iSCSI`` Cinder driver in ``/etc/kolla/globals.yml``.
 
 .. code-block:: yaml
 
-  enable_cinder_backend_pure_iscsi: "yes"
+  enable_cinder_backend_pure_iscsi: true
 
 .. end
 
@@ -21,7 +21,7 @@ configure the ``FlashArray FC`` Cinder driver in ``/etc/kolla/globals.yml``.
 
 .. code-block:: yaml
 
-  enable_cinder_backend_pure_fc: "yes"
+  enable_cinder_backend_pure_fc: true
 
 .. end
 
@@ -31,7 +31,7 @@ configure the ``FlashArray NVMe-RoCE`` Cinder driver in
 
 .. code-block:: yaml
 
-  enable_cinder_backend_pure_roce: "yes"
+  enable_cinder_backend_pure_roce: true
 
 .. end
 
@@ -45,7 +45,7 @@ configure the ``FlashArray NVMe-TCP`` Cinder driver in
 
 .. code-block:: yaml
 
-  enable_cinder_backend_pure_nvme_tcp: "yes"
+  enable_cinder_backend_pure_nvme_tcp: true
 
 .. end
 
diff --git a/doc/source/reference/storage/cinder-guide-quobyte.rst b/doc/source/reference/storage/cinder-guide-quobyte.rst
index ce38223fa..0423756b8 100644
--- a/doc/source/reference/storage/cinder-guide-quobyte.rst
+++ b/doc/source/reference/storage/cinder-guide-quobyte.rst
@@ -12,7 +12,7 @@ Cinder driver in ``/etc/kolla/globals.yml``.
 
 .. code-block:: yaml
 
-   enable_cinder_backend_quobyte: "yes"
+   enable_cinder_backend_quobyte: true
 
 .. end
 
diff --git a/doc/source/reference/storage/cinder-guide.rst b/doc/source/reference/storage/cinder-guide.rst
index 9f8a5bf2a..07192f0fb 100644
--- a/doc/source/reference/storage/cinder-guide.rst
+++ b/doc/source/reference/storage/cinder-guide.rst
@@ -65,7 +65,7 @@ Enable the ``lvm`` backend in ``/etc/kolla/globals.yml``:
 
 .. code-block:: yaml
 
-   enable_cinder_backend_lvm: "yes"
+   enable_cinder_backend_lvm: true
 
 .. note::
 
@@ -105,7 +105,7 @@ Finally, enable the ``nfs`` backend in ``/etc/kolla/globals.yml``:
 
 .. code-block:: yaml
 
-   enable_cinder_backend_nfs: "yes"
+   enable_cinder_backend_nfs: true
 
 Validation
 ~~~~~~~~~~
@@ -161,7 +161,7 @@ exist on the server and following parameter must be specified in
 
 .. code-block:: yaml
 
-   enable_cinder_backend_lvm: "yes"
+   enable_cinder_backend_lvm: true
 
 For Ubuntu and LVM2/iSCSI
 -------------------------
@@ -202,9 +202,9 @@ the following parameter must be specified in ``globals.yml``:
 
 .. code-block:: yaml
 
-   enable_cinder_backend_iscsi: "yes"
+   enable_cinder_backend_iscsi: true
 
-Also ``enable_cinder_backend_lvm`` should be set to ``no`` in this case.
+Also ``enable_cinder_backend_lvm`` should be set to ``false`` in this case.
 
 Skip Cinder prechecks for Custom backends
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/source/reference/storage/external-ceph-guide.rst b/doc/source/reference/storage/external-ceph-guide.rst
index f37678eb2..49e64d6c3 100644
--- a/doc/source/reference/storage/external-ceph-guide.rst
+++ b/doc/source/reference/storage/external-ceph-guide.rst
@@ -412,7 +412,7 @@ for Ceph includes following steps:
 
   .. code-block:: yaml
 
-     enable_manila_backend_cephfs_native: "yes"
+     enable_manila_backend_cephfs_native: true
 
 * Configure Ceph authentication details in ``/etc/kolla/globals.yml``:
 
diff --git a/doc/source/reference/storage/manila-guide.rst b/doc/source/reference/storage/manila-guide.rst
index fa0f2f11f..d0d09dce9 100644
--- a/doc/source/reference/storage/manila-guide.rst
+++ b/doc/source/reference/storage/manila-guide.rst
@@ -39,14 +39,14 @@ Cinder is required, enable it in ``/etc/kolla/globals.yml``:
 
 .. code-block:: console
 
-   enable_cinder: "yes"
+   enable_cinder: true
 
 Enable Manila and generic back end in ``/etc/kolla/globals.yml``:
 
 .. code-block:: console
 
-   enable_manila: "yes"
-   enable_manila_backend_generic: "yes"
+   enable_manila: true
+   enable_manila_backend_generic: true
 
 By default Manila uses instance flavor id 100 for its file systems. For Manila
 to work, either create a new nova flavor with id 100 (use *nova flavor-create*)
diff --git a/doc/source/reference/storage/manila-hnas-guide.rst b/doc/source/reference/storage/manila-hnas-guide.rst
index 7de399828..107205982 100644
--- a/doc/source/reference/storage/manila-hnas-guide.rst
+++ b/doc/source/reference/storage/manila-hnas-guide.rst
@@ -77,8 +77,8 @@ Enable Shared File Systems service and HNAS driver in
 
 .. code-block:: yaml
 
-   enable_manila: "yes"
-   enable_manila_backend_hnas: "yes"
+   enable_manila: true
+   enable_manila_backend_hnas: true
 
 Configure the OpenStack networking so it can reach HNAS Management
 interface and HNAS EVS Data interface.
diff --git a/doc/source/reference/storage/manila-pure-guide.rst b/doc/source/reference/storage/manila-pure-guide.rst
index 46c1f2fdf..9cb3e756a 100644
--- a/doc/source/reference/storage/manila-pure-guide.rst
+++ b/doc/source/reference/storage/manila-pure-guide.rst
@@ -61,8 +61,8 @@ Enable Shared File Systems service and FlashBlade driver in
 
 .. code-block:: yaml
 
-   enable_manila: "yes"
-   enable_manila_backend_flashblade: "yes"
+   enable_manila: true
+   enable_manila_backend_flashblade: true
 
 Configure the OpenStack networking so it can reach FlashBlade Management
 interface and FlashBlade Data interface.
diff --git a/doc/source/user/multi-regions.rst b/doc/source/user/multi-regions.rst
index 50040962c..8d4c4043a 100644
--- a/doc/source/user/multi-regions.rst
+++ b/doc/source/user/multi-regions.rst
@@ -29,8 +29,8 @@ Keystone and Horizon are enabled:
 
 .. code-block:: console
 
-   enable_keystone: "yes"
-   enable_horizon: "yes"
+   enable_keystone: true
+   enable_horizon: true
 
 Then, change the value of ``multiple_regions_names`` to add names of other
 regions. In this example, we consider two regions. The current one,
@@ -143,7 +143,7 @@ unnecessary in this region and run ``kolla-ansible``:
 
 .. code-block:: yaml
 
-   enable_keystone: "no"
-   enable_horizon: "no"
+   enable_keystone: false
+   enable_horizon: false
 
 The configuration is the same for any other region.
diff --git a/doc/source/user/operating-kolla.rst b/doc/source/user/operating-kolla.rst
index 8e931997d..44e3ddd88 100644
--- a/doc/source/user/operating-kolla.rst
+++ b/doc/source/user/operating-kolla.rst
@@ -43,7 +43,7 @@ Upgrade procedure
 
 .. note::
 
-   If you have set ``enable_cells`` to ``yes`` then you should read the
+   If you have set ``enable_cells`` to ``true`` then you should read the
    upgrade notes in the :ref:`Nova cells guide<nova-cells-upgrade>`.
 
 Kolla's strategy for upgrades is to never make a mess and to follow consistent
@@ -111,8 +111,7 @@ If performing a skip-level (SLURP) upgrade, update ``ansible`` or
 
    pip3 install --upgrade 'ansible-core>=|ANSIBLE_CORE_VERSION_MIN|,<|ANSIBLE_CORE_VERSION_MAX|.99'
 
-If upgrading to a Yoga release or later, install or upgrade Ansible Galaxy
-dependencies:
+Install or upgrade Ansible Galaxy dependencies:
 
 .. code-block:: console
 
@@ -150,7 +149,7 @@ For example:
 .. code-block:: console
 
    cp /etc/kolla/passwords.yml passwords.yml.old
-   cp kolla-ansible/etc/kolla/passwords.yml passwords.yml.new
+   cp /path/to/venv/share/kolla-ansible/etc/kolla/passwords.yml passwords.yml.new
    kolla-genpwd -p passwords.yml.new
    kolla-mergepwd --old passwords.yml.old --new passwords.yml.new --final /etc/kolla/passwords.yml
 
@@ -316,6 +315,8 @@ Tools
 -----
 
 Kolla ships with several utilities intended to facilitate ease of operation.
+If you installed Kolla Ansible in a virtual environment, these scripts are
+located in ``/path/to/venv/share/kolla-ansible/tools/``.
 
 ``tools/cleanup-containers`` is used to remove deployed containers from the
 system. This can be useful when you want to do a new clean deployment. It will
diff --git a/doc/source/user/quickstart-development.rst b/doc/source/user/quickstart-development.rst
index 6e29a2ad5..f61e972cc 100644
--- a/doc/source/user/quickstart-development.rst
+++ b/doc/source/user/quickstart-development.rst
@@ -98,7 +98,7 @@ Install Kolla-ansible
 
       git clone --branch |KOLLA_BRANCH_NAME| https://opendev.org/openstack/kolla-ansible
 
-#. Install requirements of ``kolla`` and ``kolla-ansible``:
+#. Install ``kolla-ansible`` and its dependencies:
 
    .. code-block:: console
 
@@ -160,8 +160,7 @@ manually or by running random password generator:
 
 .. code-block:: console
 
-   cd kolla-ansible/tools
-   ./generate_passwords.py
+   kolla-genpwd
 
 Kolla globals.yml
 -----------------
@@ -244,7 +243,7 @@ There are a few options that are required to deploy Kolla Ansible:
 
   By default Kolla Ansible provides a bare compute kit, however it does provide
   support for a vast selection of additional services. To enable them, set
-  ``enable_*`` to "yes".
+  ``enable_*`` to ``true``.
 
   Kolla now supports many OpenStack services, there is
   `a list of available services
@@ -283,27 +282,28 @@ need to setup basic host-level dependencies, like docker.
 Kolla Ansible provides a playbook that will install all required services in
 the correct versions.
 
-The following assumes the use of the ``all-in-one`` inventory. If using a
-different inventory, such as ``multinode``, replace the ``-i`` argument
-accordingly.
+The following assumes the use of the ``all-in-one`` inventory in your
+current directory.
+If using a different inventory, such as ``multinode``, replace the ``-i``
+argument accordingly.
 
 #. Bootstrap servers with kolla deploy dependencies:
 
   .. code-block:: console
 
-     kolla-ansible bootstrap-servers -i ../all-in-one
+     kolla-ansible bootstrap-servers -i all-in-one
 
 #. Do pre-deployment checks for hosts:
 
   .. code-block:: console
 
-     kolla-ansible prechecks -i ../all-in-one
+     kolla-ansible prechecks -i all-in-one
 
 #. Finally proceed to actual OpenStack deployment:
 
   .. code-block:: console
 
-     kolla-ansible deploy -i ../all-in-one
+     kolla-ansible deploy -i all-in-one
 
 When this playbook finishes, OpenStack should be up, running and functional!
 If error occurs during execution, refer to
diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst
index f02401fc2..f2978b95a 100644
--- a/doc/source/user/quickstart.rst
+++ b/doc/source/user/quickstart.rst
@@ -235,11 +235,11 @@ There are a few options that are required to deploy Kolla Ansible:
 
   By default Kolla Ansible provides a bare compute kit, however it does provide
   support for a vast selection of additional services. To enable them, set
-  ``enable_*`` to "yes".
+  ``enable_*`` to ``true``.
 
   Kolla now supports many OpenStack services, there is
   `a list of available services
-  <https://github.com/openstack/kolla-ansible/blob/master/README.rst#openstack-services>`_.
+  <https://opendev.org/openstack/kolla-ansible/src/branch/|KOLLA_BRANCH_NAME|/README.rst#openstack-services>`_.
   For more information about service configuration, Please refer to the
   :kolla-ansible-doc:`Services Reference Guide <reference/index.html>`.
 
diff --git a/doc/source/user/troubleshooting.rst b/doc/source/user/troubleshooting.rst
index 76a9ac604..289b89220 100644
--- a/doc/source/user/troubleshooting.rst
+++ b/doc/source/user/troubleshooting.rst
@@ -48,7 +48,7 @@ Debugging Kolla
 ~~~~~~~~~~~~~~~
 
 The status of containers after deployment can be determined on the deployment
-targets by executing:
+targets by executing (use `podman` instead of `docker` if applicable):
 
 .. code-block:: console
 
@@ -76,8 +76,10 @@ If the stdout logs are needed, please run:
 Note that most of the containers don't log to stdout so the above command will
 provide no information.
 
-To learn more about Docker command line operation please refer to `Docker
-documentation <https://docs.docker.com/reference/>`__.
+To learn more about container engine command line operation, please refer
+to the `Docker
+documentation <https://docs.docker.com/reference/>`__ or the `Podman
+documentation <https://docs.podman.io/en/stable/Commands.html>`__.
 
 The log volume "kolla_logs" is linked to ``/var/log/kolla`` on the host.
 You can find all kolla logs in there.