Skip to content

Commit

Permalink
docs: Deindent code blocks
Browse files Browse the repository at this point in the history 
We had a number of code blocks that were being incorrectly rendered
inside block quotes, which messed with formatting somewhat. Correct
them. This was done using the following script:

  sphinx-build -W -b xml doc/source doc/build/xml
  files=$(find doc/build/xml -name '*.xml' -print)
  for file in $files; do
      if xmllint -xpath "//block_quote/literal_block" "$file" &>/dev/null; then
          echo "$file"
      fi
  done

Note that this also highlighted a file using DOS line endings. This is
corrected.

Change-Id: If63f31bf13c76a185e2c6eebc9b85f9a1f3bbde8
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
  • Loading branch information
@stephenfin
stephenfin committed May 10, 2023
1 parent 272a315 commit d409296
Show file tree
Hide file tree
Showing 10 changed files with 749 additions and 757 deletions.
420 changes: 209 additions & 211 deletions doc/source/admin/config-bgp-floating-ip-over-l2-segmented-network.rst
View file

Large diffs are not rendered by default.

656 changes: 328 additions & 328 deletions doc/source/admin/config-logging.rst
View file

Large diffs are not rendered by default.

3 changes: 1 addition & 2 deletions doc/source/admin/config-ovs-offload.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand All @@ -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
Expand Down
3 changes: 1 addition & 2 deletions doc/source/admin/config-qos.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -268,13 +268,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
Expand Down
2 changes: 1 addition & 1 deletion doc/source/admin/config-routed-networks.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -634,7 +634,7 @@ creating multiple networks and/or increasing broadcast domain.
example, the second segment uses the ``provider1`` physical network
with VLAN ID 2020.

.. code-block:: console
.. code-block:: console
$ openstack network segment create --physical-network provider1 \
--network-type vlan --segment 2020 --network multisegment1 segment1-2
Expand Down
98 changes: 49 additions & 49 deletions doc/source/admin/ovn/routed_provider_networks.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down
44 changes: 20 additions & 24 deletions doc/source/admin/ovn/troubleshooting.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ the host to the OVN database by creating the corresponding "Chassis" and
when the process is gracefully stopped, it deletes both registers. These
registers are used by Neutron to control the OVN agents.

.. code-block:: console
.. code-block:: console
$ openstack network agent list -c ID -c "Agent Type" -c Host -c Alive -c State
+--------------------------------------+------------------------------+--------+-------+-------+
Expand All @@ -76,40 +76,36 @@ the other one will be down because the "Chassis_Private.nb_cfg_timestamp"
is not updated. In this case, the administrator should manually delete from
the OVN Southbound database the stale registers. For example:

* List the "Chassis" registers, filtering by hostname and name (OVS
"system-id"):

.. code-block:: console
$ sudo ovn-sbctl list Chassis | grep name
hostname : u20ovn
name : "a55c8d85-2071-4452-92cb-95d15c29bde7"
hostname : u20ovn
name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"


* Delete the stale "Chassis" register:
* List the "Chassis" registers, filtering by hostname and name (OVS
"system-id"):

.. code-block:: console
.. code-block:: console
$ sudo ovn-sbctl destroy Chassis ce9a1471-79c1-4472-adfc-9e5ce86eba07
$ sudo ovn-sbctl list Chassis | grep name
hostname : u20ovn
name : "a55c8d85-2071-4452-92cb-95d15c29bde7"
hostname : u20ovn
name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"
* Delete the stale "Chassis" register:

* List the "Chassis_Private" registers, filtering by name:
.. code-block:: console
.. code-block:: console
$ sudo ovn-sbctl destroy Chassis ce9a1471-79c1-4472-adfc-9e5ce86eba07
$ sudo ovn-sbctl list Chassis_Private | grep name
name : "a55c8d85-2071-4452-92cb-95d15c29bde7"
name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"
* List the "Chassis_Private" registers, filtering by name:

.. code-block:: console
* Delete the stale "Chassis_Private" register:
$ sudo ovn-sbctl list Chassis_Private | grep name
name : "a55c8d85-2071-4452-92cb-95d15c29bde7"
name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"
.. code-block:: console
* Delete the stale "Chassis_Private" register:

$ sudo ovn-sbctl destroy Chassis_Private ce9a1471-79c1-4472-adfc-9e5ce86eba07
.. code-block:: console
$ sudo ovn-sbctl destroy Chassis_Private ce9a1471-79c1-4472-adfc-9e5ce86eba07
If the host name is also updated during the system upgrade, the Neutron
agent list could present entries from different host names, but the older
Expand Down
56 changes: 28 additions & 28 deletions doc/source/configuration/metering-agent.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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

0 comments on commit d409296

Please sign in to comment.