Merge "docs: Deindent code blocks" into stable/zed

Author: Zuul

doc/source/admin/config-bgp-floating-ip-over-l2-segmented-network.rst

@@ -166,7 +166,7 @@ network and has access to the private networks of all nodes.
       The PCI bus number of the PF (03:00.0) and VFs (03:00.2 .. 03:00.5)
       will be used later.
 
-   .. code-block::bash
+   .. code-block:: bash
 
       # lspci | grep Ethernet
       03:00.0 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5]
@@ -176,7 +176,6 @@ network and has access to the private networks of all nodes.
       03:00.4 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5 Virtual Function]
       03:00.5 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5 Virtual Function]
 
-
    .. code-block:: bash
 
       # ip link show enp3s0f0

doc/source/admin/config-logging.rst

@@ -267,13 +267,12 @@ On the network and compute nodes:
       [agent]
       extensions = fip_qos, gateway_ip_qos
 
-
 #. As rate limit doesn't work on Open vSwitch's ``internal`` ports,
    optionally, as a workaround, to make QoS bandwidth limit work on
    router's gateway ports, set ``ovs_use_veth`` to ``True`` in ``DEFAULT``
    section in ``/etc/neutron/l3_agent.ini``
 
-  .. code-block:: ini
+   .. code-block:: ini
 
       [DEFAULT]
       ovs_use_veth = True

doc/source/admin/config-ovs-offload.rst

@@ -16,55 +16,55 @@ For example, in the OVN Northbound database, this is how a VLAN
 Provider Network with two segments (VLAN: 100, 200) is related to their
 ``Logical_Switch`` counterpart:
 
-  .. code-block:: bash
+.. code-block:: bash
 
-     $ ovn-nbctl list logical_switch public
-     _uuid               : 983719e5-4f32-4fb0-926d-46291457ca41
-     acls                : []
-     dns_records         : []
-     external_ids        : {"neutron:mtu"="1450", "neutron:network_name"=public, "neutron:revision_number"="3"}
-     forwarding_groups   : []
-     load_balancer       : []
-     name                : neutron-6c8be12a-9ed0-4ac4-8130-cb8fad83cd46
-     other_config        : {mcast_flood_unregistered="false", mcast_snoop="true"}
-     ports               : [81bce1ab-87f8-4ed5-8163-f16701499dfe, b23d0c2e-773b-4ecb-8306-53d117006a7b]
-     qos_rules           : []
+   $ ovn-nbctl list logical_switch public
+   _uuid               : 983719e5-4f32-4fb0-926d-46291457ca41
+   acls                : []
+   dns_records         : []
+   external_ids        : {"neutron:mtu"="1450", "neutron:network_name"=public, "neutron:revision_number"="3"}
+   forwarding_groups   : []
+   load_balancer       : []
+   name                : neutron-6c8be12a-9ed0-4ac4-8130-cb8fad83cd46
+   other_config        : {mcast_flood_unregistered="false", mcast_snoop="true"}
+   ports               : [81bce1ab-87f8-4ed5-8163-f16701499dfe, b23d0c2e-773b-4ecb-8306-53d117006a7b]
+   qos_rules           : []
 
-     $ ovn-nbctl list logical_switch_port 81bce1ab-87f8-4ed5-8163-f16701499dfe
-     _uuid               : 81bce1ab-87f8-4ed5-8163-f16701499dfe
-     addresses           : [unknown]
-     dhcpv4_options      : []
-     dhcpv6_options      : []
-     dynamic_addresses   : []
-     enabled             : []
-     external_ids        : {}
-     ha_chassis_group    : []
-     name                : provnet-96f663af-19fa-4c7e-a1b8-1dfdc9cd9e82
-     options             : {network_name=phys-net-1}
-     parent_name         : []
-     port_security       : []
-     tag                 : 100
-     tag_request         : []
-     type                : localnet
-     up                  : false
+   $ ovn-nbctl list logical_switch_port 81bce1ab-87f8-4ed5-8163-f16701499dfe
+   _uuid               : 81bce1ab-87f8-4ed5-8163-f16701499dfe
+   addresses           : [unknown]
+   dhcpv4_options      : []
+   dhcpv6_options      : []
+   dynamic_addresses   : []
+   enabled             : []
+   external_ids        : {}
+   ha_chassis_group    : []
+   name                : provnet-96f663af-19fa-4c7e-a1b8-1dfdc9cd9e82
+   options             : {network_name=phys-net-1}
+   parent_name         : []
+   port_security       : []
+   tag                 : 100
+   tag_request         : []
+   type                : localnet
+   up                  : false
 
-     $ ovn-nbctl list logical_switch_port b23d0c2e-773b-4ecb-8306-53d117006a7b
-     _uuid               : b23d0c2e-773b-4ecb-8306-53d117006a7b
-     addresses           : [unknown]
-     dhcpv4_options      : []
-     dhcpv6_options      : []
-     dynamic_addresses   : []
-     enabled             : []
-     external_ids        : {}
-     ha_chassis_group    : []
-     name                : provnet-469cbc3d-8e06-4a8f-be3a-3fcdadfd398a
-     options             : {network_name=phys-net-2}
-     parent_name         : []
-     port_security       : []
-     tag                 : 200
-     tag_request         : []
-     type                : localnet
-     up                  : false
+   $ ovn-nbctl list logical_switch_port b23d0c2e-773b-4ecb-8306-53d117006a7b
+   _uuid               : b23d0c2e-773b-4ecb-8306-53d117006a7b
+   addresses           : [unknown]
+   dhcpv4_options      : []
+   dhcpv6_options      : []
+   dynamic_addresses   : []
+   enabled             : []
+   external_ids        : {}
+   ha_chassis_group    : []
+   name                : provnet-469cbc3d-8e06-4a8f-be3a-3fcdadfd398a
+   options             : {network_name=phys-net-2}
+   parent_name         : []
+   port_security       : []
+   tag                 : 200
+   tag_request         : []
+   type                : localnet
+   up                  : false
 
 
 As you can see, the two ``localnet`` ports are configured with a
@@ -73,10 +73,10 @@ VLAN tag and are related to a single ``Logical_Switch`` entry. When
 node it's running on it will create a patch port to the provider bridge
 accordingly to the bridge mappings configuration.
 
-  .. code-block:: bash
+.. code-block:: bash
 
-     compute-1: bridge-mappings = segment-1:br-provider1
-     compute-2: bridge-mappings = segment-2:br-provider2
+   compute-1: bridge-mappings = segment-1:br-provider1
+   compute-2: bridge-mappings = segment-2:br-provider2
 
 For example, when a port in the multisegment network gets bound to
 compute-1, ovn-controller will create a patch-port between br-int and

doc/source/admin/config-qos.rst

@@ -42,18 +42,18 @@ also called as legacy) have the following format; bear in mind that if labels
 are shared, then the counters are for all routers of all projects where the
 labels were applied.
 
-  .. code-block:: json
-
-     {
-      "pkts": "<the number of packets that matched the rules of the labels>",
-      "bytes": "<the number of bytes that matched the rules of the labels>",
-      "time": "<seconds between the first data collection and the last one>",
-      "first_update": "timeutils.utcnow_ts() of the first collection",
-      "last_update": "timeutils.utcnow_ts() of the last collection",
-      "host": "<neutron metering agent host name>",
-      "label_id": "<the label id>",
-      "tenant_id": "<the tenant id>"
-      }
+.. code-block:: json
+
+   {
+    "pkts": "<the number of packets that matched the rules of the labels>",
+    "bytes": "<the number of bytes that matched the rules of the labels>",
+    "time": "<seconds between the first data collection and the last one>",
+    "first_update": "timeutils.utcnow_ts() of the first collection",
+    "last_update": "timeutils.utcnow_ts() of the last collection",
+    "host": "<neutron metering agent host name>",
+    "label_id": "<the label id>",
+    "tenant_id": "<the tenant id>"
+    }
 
 The ``first_update`` and ``last_update`` timestamps represent the moment
 when the first and last data collection happened within the report interval.
@@ -129,21 +129,21 @@ legacy mode such as ``bytes``, ``pkts``, ``time``, ``first_update``,
 ``last_update``, and ``host``. As follows we present an example of JSON message
 with all of the possible attributes.
 
-  .. code-block:: json
-
-     {
-     "resource_id": "router-f0f745d9a59c47fdbbdd187d718f9e41-label-00c714f1-49c8-462c-8f5d-f05f21e035c7",
-      "project_id": "f0f745d9a59c47fdbbdd187d718f9e41",
-      "first_update": 1591058790,
-      "bytes": 0,
-      "label_id": "00c714f1-49c8-462c-8f5d-f05f21e035c7",
-      "label_name": "test1",
-      "last_update": 1591059037,
-      "host": "<hostname>",
-      "time": 247,
-      "pkts": 0,
-      "label_shared": true
-      }
+.. code-block:: json
+
+   {
+       "resource_id": "router-f0f745d9a59c47fdbbdd187d718f9e41-label-00c714f1-49c8-462c-8f5d-f05f21e035c7",
+       "project_id": "f0f745d9a59c47fdbbdd187d718f9e41",
+       "first_update": 1591058790,
+       "bytes": 0,
+       "label_id": "00c714f1-49c8-462c-8f5d-f05f21e035c7",
+       "label_name": "test1",
+       "last_update": 1591059037,
+       "host": "<hostname>",
+       "time": 247,
+       "pkts": 0,
+       "label_shared": true
+   }
 
 The ``resource_id`` is a unique identified for the "resource" being
 monitored. Here we consider a resource to be any of the granularities that
@@ -156,4 +156,4 @@ As follows we present all of the possible configuration one can use in the
 metering agent init file.
 
 .. show-options::
-   :config-file: etc/oslo-config-generator/metering_agent.ini
+   :config-file: etc/oslo-config-generator/metering_agent.ini

doc/source/admin/ovn/routed_provider_networks.rst

@@ -10,10 +10,10 @@ manage affected security group rules. Thus, there is no need for an agent.
 It is good to keep in mind that Openstack Security Groups (SG) and their rules
 (SGR) map 1:1 into OVN's Port Groups (PG) and Access Control Lists (ACL):
 
-  .. code-block:: none
+.. code-block:: none
 
-     Openstack Security Group <=> OVN Port Group
-     Openstack Security Group Rule <=> OVN ACL
+   Openstack Security Group <=> OVN Port Group
+   Openstack Security Group Rule <=> OVN ACL
 
 Just like SGs have a list of SGRs, PGs have a list of ACLs. PGs also have
 a list of logical ports, but that is not really relevant in this context.
@@ -50,22 +50,22 @@ https://github.com/ovn-org/ovn/commit/880dca99eaf73db7e783999c29386d03c82093bf
 Below is an example of a meter configuration in OVN. You can locate the fair,
 unit, burst_size, and rate attributes:
 
-  .. code-block:: bash
+.. code-block:: bash
 
-     $ ovn-nbctl list meter
-     _uuid               : 70c76ba9-f303-471b-9d49-25dee299827f
-     bands               : [f114c205-a170-4425-8ca6-4e71099d1955]
-     external_ids        : {"neutron:device_owner"=logging-plugin}
-     fair                : true
-     name                : acl_log_meter
-     unit                : pktps
+   $ ovn-nbctl list meter
+   _uuid               : 70c76ba9-f303-471b-9d49-25dee299827f
+   bands               : [f114c205-a170-4425-8ca6-4e71099d1955]
+   external_ids        : {"neutron:device_owner"=logging-plugin}
+   fair                : true
+   name                : acl_log_meter
+   unit                : pktps
 
-     $ ovn-nbctl list meter-band
-     _uuid               : f114c205-a170-4425-8ca6-4e71099d1955
-     action              : drop
-     burst_size          : 25
-     external_ids        : {}
-     rate                : 100
+   $ ovn-nbctl list meter-band
+   _uuid               : f114c205-a170-4425-8ca6-4e71099d1955
+   action              : drop
+   burst_size          : 25
+   external_ids        : {}
+   rate                : 100
 
 The burst_size and rate attributes are configurable through
 neutron.conf.services.logging.log_driver_opts. That is not new.
@@ -78,39 +78,39 @@ Moreover, there are a few attributes in each ACL that makes it able to
 provide the networking logging feature. Let's use the example below
 to point out the relevant fields:
 
-  .. code-block:: none
-
-     $ openstack network log create --resource-type security_group \
-       --resource ${SG} --event ACCEPT logme -f value -c ID
-     2e456c7f-154e-40a8-bb10-f88ba51b90b5
-
-     $ openstack security group show ${SG} -f json -c rules | jq '.rules | .[2]' | grep -v 'null'
-     {
-      "id": "de4ea1e4-c946-40ed-b5b6-53c59418dc0b",
-      "tenant_id": "2600067ea3a446dba332d20a30ed44fa",
-      "security_group_id": "c604e984-0789-4c9a-a297-3e7f62fa73fd",
-      "ethertype": "IPv4",
-      "direction": "egress",
-      "standard_attr_id": 48,
-      "tags": [],
-      "created_at": "2021-02-06T22:17:44Z",
-      "updated_at": "2021-02-06T22:17:44Z",
-      "revision_number": 0,
-      "project_id": "2600067ea3a446dba332d20a30ed44fa"
-    }
-
-    $ ovn-nbctl find acl \
-      "external_ids:\"neutron:security_group_rule_id\""="de4ea1e4-c946-40ed-b5b6-53c59418dc0b"
-    _uuid               : 791679e9-237d-4732-a31e-aa634496e02b
-    action              : allow-related
-    direction           : from-lport
-    external_ids        : {"neutron:security_group_rule_id"="de4ea1e4-c946-40ed-b5b6-53c59418dc0b"}
-    log                 : true
-    match               : "inport == @pg_c604e984_0789_4c9a_a297_3e7f62fa73fd && ip4"
-    meter               : acl_log_meter
-    name                : neutron-2e456c7f-154e-40a8-bb10-f88ba51b90b5
-    priority            : 1002
-    severity            : info
+.. code-block:: none
+
+   $ openstack network log create --resource-type security_group \
+     --resource ${SG} --event ACCEPT logme -f value -c ID
+   2e456c7f-154e-40a8-bb10-f88ba51b90b5
+
+   $ openstack security group show ${SG} -f json -c rules | jq '.rules | .[2]' | grep -v 'null'
+   {
+    "id": "de4ea1e4-c946-40ed-b5b6-53c59418dc0b",
+    "tenant_id": "2600067ea3a446dba332d20a30ed44fa",
+    "security_group_id": "c604e984-0789-4c9a-a297-3e7f62fa73fd",
+    "ethertype": "IPv4",
+    "direction": "egress",
+    "standard_attr_id": 48,
+    "tags": [],
+    "created_at": "2021-02-06T22:17:44Z",
+    "updated_at": "2021-02-06T22:17:44Z",
+    "revision_number": 0,
+    "project_id": "2600067ea3a446dba332d20a30ed44fa"
+  }
+
+  $ ovn-nbctl find acl \
+    "external_ids:\"neutron:security_group_rule_id\""="de4ea1e4-c946-40ed-b5b6-53c59418dc0b"
+  _uuid               : 791679e9-237d-4732-a31e-aa634496e02b
+  action              : allow-related
+  direction           : from-lport
+  external_ids        : {"neutron:security_group_rule_id"="de4ea1e4-c946-40ed-b5b6-53c59418dc0b"}
+  log                 : true
+  match               : "inport == @pg_c604e984_0789_4c9a_a297_3e7f62fa73fd && ip4"
+  meter               : acl_log_meter
+  name                : neutron-2e456c7f-154e-40a8-bb10-f88ba51b90b5
+  priority            : 1002
+  severity            : info
 
 The first command creates a networking-log for a given SG. The second shows an SGR from that SG.
 The third shell command is where we can see how the ACL with the meter information gets populated.
@@ -128,14 +128,14 @@ These are the attributes pertinent to network logging:
 If we poked the SGR with packets that match its criteria, the ovn-controller local to where the ACLs
 is enforced will log something that looks like this:
 
-  .. code-block:: none
+.. code-block:: none
 
-     2021-02-16T11:59:00.640Z|00045|acl_log(ovn_pinctrl0)|INFO|
-     name="neutron-2e456c7f-154e-40a8-bb10-f88ba51b90b5",
-     verdict=allow, severity=info: icmp,vlan_tci=0x0000,dl_src=fa:16:3e:24:dc:88,
-     dl_dst=fa:16:3e:15:6d:e0,
-     nw_src=10.0.0.12,nw_dst=10.0.0.11,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,
-     icmp_code=0
+   2021-02-16T11:59:00.640Z|00045|acl_log(ovn_pinctrl0)|INFO|
+   name="neutron-2e456c7f-154e-40a8-bb10-f88ba51b90b5",
+   verdict=allow, severity=info: icmp,vlan_tci=0x0000,dl_src=fa:16:3e:24:dc:88,
+   dl_dst=fa:16:3e:15:6d:e0,
+   nw_src=10.0.0.12,nw_dst=10.0.0.11,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,
+   icmp_code=0
 
 It is beyond the scope of this document to talk about what happens after the logs are generated
 by ovn-controllers. The harvesting of files across compute nodes is something a project like