6 files changed, 18 insertions, 28 deletions
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