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>
(cherry picked from commit d409296)
(cherry picked from commit 1ef6a60)
Conflicts:
	doc/source/admin/config-routed-networks.rst
  • Loading branch information
@stephenfin @karelyatin
stephenfin authored and karelyatin committed May 16, 2023
1 parent 1864dd8 commit 438e486
Show file tree
Hide file tree
Showing 8 changed files with 728 additions and 732 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
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
Expand Up @@ -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
Expand Down
98 changes: 49 additions & 49 deletions doc/source/admin/ovn/routed_provider_networks.rst
View file
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
56 changes: 28 additions & 28 deletions doc/source/configuration/metering-agent.rst
View file
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
114 changes: 57 additions & 57 deletions doc/source/contributor/internals/ovn/ovn_network_logging.rst
View file
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand All @@ -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.
Expand All @@ -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
Expand Down

0 comments on commit 438e486

Please sign in to comment.