openstack/neutron
Code Issues Proposed changes

Merge "Add RST linting to neutron"

Browse Source
This commit is contained in:
Zuul 2024-10-02 09:05:05 +00:00 committed by Gerrit Code Review
commit ba8550ddd0
86 changed files with 1015 additions and 822 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
TESTING.rst
View File

@ -97,10 +97,10 @@ At the end of each test run:
* The in-memory database is cleared of content, but its schema is maintained.
* The global Oslo configuration object is reset.
The unit testing framework can be used to effectively test database interaction,
for example, distributed routers allocate a MAC address for every host running
an OVS agent. One of DVR's DB mixins implements a method that lists all host
MAC addresses. Its test looks like this:
The unit testing framework can be used to effectively test database
interaction, for example, distributed routers allocate a MAC address for
every host running an OVS agent. One of DVR's DB mixins implements a method
that lists all host MAC addresses. Its test looks like this:
.. code-block:: python
@ -159,9 +159,9 @@ One of its methods is called 'device_exists' which accepts a device name
and a namespace and returns True if the device exists in the given namespace.
It's easy building a test that targets the method directly, and such a test
would be considered a 'unit' test. However, what framework should such a test
use? A test using the unit tests framework could not mutate state on the system,
and so could not actually create a device and assert that it now exists. Such
a test would look roughly like this:
use? A test using the unit tests framework could not mutate state on the
system, and so could not actually create a device and assert that it now
exists. Such a test would look roughly like this:
* It would mock 'execute', a method that executes shell commands against the
system to return an IP device named 'foo'.
@ -261,9 +261,10 @@ should be validated, and all interaction with the daemon should be via
a REST client.
The neutron-tempest-plugin/neutron_tempest_plugin directory was copied from the
Tempest project around the Kilo timeframe. At the time, there was an overlap of tests
between the Tempest and Neutron repositories. This overlap was then eliminated by carving
out a subset of resources that belong to Tempest, with the rest in Neutron.
Tempest project around the Kilo timeframe. At the time, there was an overlap of
tests between the Tempest and Neutron repositories. This overlap was then
eliminated by carving out a subset of resources that belong to Tempest, with
the rest in Neutron.
API tests that belong to Tempest deal with a subset of Neutron's resources:
@ -296,9 +297,10 @@ define a list of required extensions for particular test class.
Scenario Tests
~~~~~~~~~~~~~~
Scenario tests (neutron-tempest-plugin/neutron_tempest_plugin/scenario), like API tests,
use the Tempest test infrastructure and have the same requirements. Guidelines for
writing a good scenario test may be found at the Tempest developer guide:
Scenario tests (neutron-tempest-plugin/neutron_tempest_plugin/scenario), like
API tests, use the Tempest test infrastructure and have the same requirements.
Guidelines for writing a good scenario test may be found at the Tempest
developer guide:
https://docs.openstack.org/tempest/latest/field_guide/scenario.html
Scenario tests, like API tests, are split between the Tempest and Neutron
@ -322,15 +324,18 @@ Specific test requirements for advanced images are:
Rally Tests
~~~~~~~~~~~
Rally tests (rally-jobs/plugins) use the `rally <http://rally.readthedocs.io/>`_
infrastructure to exercise a neutron deployment. Guidelines for writing a
good rally test can be found in the `rally plugin documentation <http://rally.readthedocs.io/en/latest/plugins/>`_.
Rally tests (rally-jobs/plugins) use the
`rally <http://rally.readthedocs.io/>`_ infrastructure to exercise a neutron
deployment. Guidelines for writing a good rally test can be found in the
`rally plugin documentation <http://rally.readthedocs.io/en/latest/plugins/>`_.
There are also some examples in tree; the process for adding rally plugins to
neutron requires three steps: 1) write a plugin and place it under rally-jobs/plugins/.
This is your rally scenario; 2) (optional) add a setup file under rally-jobs/extra/.
This is any devstack configuration required to make sure your environment can
successfully process your scenario requests; 3) edit neutron-neutron.yaml. This
is your scenario 'contract' or SLA.
neutron requires three steps:
1) write a plugin and place it under rally-jobs/plugins/. This is your rally
scenario;
2) (optional) add a setup file under rally-jobs/extra/. This is any devstack
configuration required to make sure your environment can successfully process
your scenario requests;
3) edit neutron-neutron.yaml. This is your scenario 'contract' or SLA.
Grenade Tests
~~~~~~~~~~~~~
@ -346,8 +351,8 @@ similar to deploying OpenStack using Devstack. All is described in the
`Project's wiki <https://wiki.openstack.org/wiki/Grenade>`_ and `documentation
<https://opendev.org/openstack/grenade/src/branch/master/README.rst>`_.
More info about how to troubleshoot Grenade failures in the CI jobs can be found
in the :ref:`Troubleshooting Grenade jobs <troubleshooting-grenade-jobs>`
More info about how to troubleshoot Grenade failures in the CI jobs can be
found in the :ref:`Troubleshooting Grenade jobs <troubleshooting-grenade-jobs>`
document.
Development Process
@ -438,8 +443,11 @@ To run only pep8::
tox -e pep8
Since pep8 includes running pylint on all files, it can take quite some time to run.
To restrict the pylint check to only the files altered by the latest patch changes::
Since pep8 includes running pylint on all files, it can take quite some time
to run.
To restrict the pylint check to only the files altered by the latest patch
changes::
tox -e pep8 HEAD~1

12
doc/source/admin/archives/auth.rst
View File

@ -90,7 +90,7 @@ This extract is from the default ``policy.yaml`` file:
administrator or the owner of the resource specified in the request
(project identifier is equal).
.. code-block:: none
.. code-block:: yaml
"admin_or_owner": "role:admin or tenant_id:%(tenant_id)s"
"admin_or_network_owner": "role:admin or tenant_id:%(network_tenant_id)s"
@ -101,7 +101,7 @@ This extract is from the default ``policy.yaml`` file:
- The default policy that is always evaluated if an API operation does
not match any of the policies in ``policy.yaml``.
.. code-block:: none
.. code-block:: yaml
"default": "rule:admin_or_owner"
"create_subnet": "rule:admin_or_network_owner"
@ -113,7 +113,7 @@ This extract is from the default ``policy.yaml`` file:
- This policy evaluates successfully if either *admin_or_owner*, or
*shared* evaluates successfully.
.. code-block:: none
.. code-block:: yaml
"get_network": "rule:admin_or_owner or rule:shared"
"create_network:shared": "rule:admin_only"
@ -121,7 +121,7 @@ This extract is from the default ``policy.yaml`` file:
- This policy restricts the ability to manipulate the *shared*
attribute for a network to administrators only.
.. code-block:: none
.. code-block:: yaml
"update_network": "rule:admin_or_owner"
"delete_network": "rule:admin_or_owner"
@ -133,7 +133,7 @@ This extract is from the default ``policy.yaml`` file:
attribute for a port only to administrators and the owner of the
network where the port is attached.
.. code-block:: none
.. code-block:: yaml
"get_port": "rule:admin_or_owner"
"update_port": "rule:admin_or_owner"
@ -144,7 +144,7 @@ This example shows you how to modify a policy file to permit project to
define networks, see their resources, and permit administrative users to
perform all other operations:
.. code-block:: none
.. code-block:: yaml
"admin_or_owner": "role:admin or tenant_id:%(tenant_id)s"
"admin_only": "role:admin"

3
doc/source/admin/archives/introduction.rst
View File

@ -107,7 +107,8 @@ Set these options to configure SSL:
Firewall-as-a-Service (FWaaS) overview
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For information on Firewall-as-a-Service (FWaaS), please consult the :doc:`Networking Guide <../fwaas>`.
For information on Firewall-as-a-Service (FWaaS), please consult the
:doc:`Networking Guide <../fwaas>`.
Allowed-address-pairs
~~~~~~~~~~~~~~~~~~~~~

3
doc/source/admin/config-active-active-l3gw.rst
View File

@ -130,7 +130,8 @@ can be set per router at router creation time by passing the
``--enable-default-route-bfd`` argument or by updating an existing router using
the ``openstack router set`` command.
The default behavior for new routers can be controlled using the `enable_default_route_bfd`_ configuration option.
The default behavior for new routers can be controlled using the
`enable_default_route_bfd`_ configuration option.
It is recommended to enable this when `adding multiple default routes to a
router`_ as failure to do so will lead to degraded performance in the event of

22
doc/source/admin/config-dns-int-ext-serv.rst
View File

@ -47,10 +47,11 @@ Once this is done, the user has to take the following steps and restart
Networking service to create and update reverse lookup (PTR) zones.
* ``project_name``: the name of the project to be used by the
Networking service to create and update reverse lookup (PTR) zones.
* ``project_domain_name``: the name of the domain for the project to be used by the
Networking service to create and update reverse lookup (PTR) zones.
* ``user_domain_name``: the name of the domain for the user to be used by the
Networking service to create and update reverse lookup (PTR) zones.
* ``project_domain_name``: the name of the domain for the project to be
used by the Networking service to create and update reverse lookup (PTR)
zones.
* ``user_domain_name``: the name of the domain for the user to be used by
the Networking service to create and update reverse lookup (PTR) zones.
* ``region_name``: the name of the region to be used by the
Networking service to create and update reverse lookup (PTR) zones.
* ``allow_reverse_dns_lookup``: a boolean value specifying whether to enable
@ -60,10 +61,11 @@ Once this is done, the user has to take the following steps and restart
* ``ipv6_ptr_zone_prefix_size``: the size in bits of the prefix for the IPv6
reverse lookup (PTR) zones.
* ``ptr_zone_email``: the email address to use when creating new reverse
lookup (PTR) zones. The default is ``admin@<dns_domain>`` where ``<dns_domain>``
is the domain for the first record being created in that zone.
* ``insecure``: whether to disable SSL certificate validation. By default, certificates
are validated.
lookup (PTR) zones. The default is ``admin@<dns_domain>`` where
``<dns_domain>`` is the domain for the first record being created in that
zone.
* ``insecure``: whether to disable SSL certificate validation. By default,
certificates are validated.
* ``cafile``: Path to a valid Certificate Authority (CA) certificate.
Optional, the system CAs are used as default.
@ -908,8 +910,8 @@ Only for :ref:`config-dns-use-case-3`, if the port binding extension is
enabled in the Networking service, the Compute service will execute one
additional port update operation when allocating the port for the instance
during the boot process. This may have a noticeable adverse effect in the
performance of the boot process that should be evaluated before adoption of this
use case.
performance of the boot process that should be evaluated before adoption of
this use case.
.. _config-dns-int-ext-serv-net:

2
doc/source/admin/config-experimental-framework.rst
View File

@ -31,7 +31,7 @@ experimetal:
This is an example of how to enable the use of an experimental feature:
.. code-block:: none
.. code-block:: ini
[experimental]
linuxbridge = true

10
doc/source/admin/config-ipv6.rst
View File

@ -350,8 +350,8 @@ follows:
Setting DHCPv6-stateless for ``ipv6_ra_mode`` configures the neutron
router with an radvd agent to send Router Advertisements. The list below
captures the values set for the address configuration flags in the Router
Advertisement messages in this scenario. Similarly, setting DHCPv6-stateless for
``ipv6_address_mode`` configures neutron DHCP implementation to provide
Advertisement messages in this scenario. Similarly, setting DHCPv6-stateless
for ``ipv6_address_mode`` configures neutron DHCP implementation to provide
the additional network information.
* Autonomous Address Configuration Flag = 1
@ -361,8 +361,8 @@ the additional network information.
Setting DHCPv6-stateful for ``ipv6_ra_mode`` configures the neutron
router with an radvd agent to send Router Advertisements. The list below
captures the values set for the address configuration flags in the Router
Advertisements messages in this scenario. Similarly, setting DHCPv6-stateful for
``ipv6_address_mode`` configures neutron DHCP implementation to provide
Advertisements messages in this scenario. Similarly, setting DHCPv6-stateful
for ``ipv6_address_mode`` configures neutron DHCP implementation to provide
addresses and additional network information through DHCPv6.
* Autonomous Address Configuration Flag = 0
@ -609,7 +609,7 @@ Configuring the Dibbler server
After installing Dibbler, edit the ``/etc/dibbler/server.conf`` file:
.. code-block:: none
.. code-block::
script "/var/lib/dibbler/pd-server.sh"

31
doc/source/admin/config-logging.rst
View File

@ -40,7 +40,7 @@ Service Configuration
To enable the logging service, add ``log`` to the ``service_plugins`` setting
in ``/etc/neutron/neutron.conf``:
.. code-block:: none
.. code-block:: ini
service_plugins = router,metering,log
@ -181,13 +181,14 @@ To enable the logging service, follow the below steps.
#. On Neutron controller node, add ``log`` to ``service_plugins`` setting in
``/etc/neutron/neutron.conf`` file. For example:
.. code-block:: none
.. code-block:: ini
service_plugins = router,metering,log
#. To enable logging service for ``security_group`` in Layer 2, add ``log`` to
option ``extensions`` in section ``[agent]`` in ``/etc/neutron/plugins/ml2/ml2_conf.ini``
for controller node and in ``/etc/neutron/plugins/ml2/openvswitch_agent.ini``
option ``extensions`` in section ``[agent]`` in
``/etc/neutron/plugins/ml2/ml2_conf.ini`` for controller node and in
``/etc/neutron/plugins/ml2/openvswitch_agent.ini``
for compute/network nodes. For example:
.. code-block:: ini
@ -210,8 +211,8 @@ To enable the logging service, follow the below steps.
extensions = fwaas_v2,fwaas_v2_log
#. On compute/network nodes, add configuration for logging service to
``[network_log]`` in ``/etc/neutron/plugins/ml2/openvswitch_agent.ini`` and in
``/etc/neutron/l3_agent.ini`` as shown below:
``[network_log]`` in ``/etc/neutron/plugins/ml2/openvswitch_agent.ini``
and in ``/etc/neutron/l3_agent.ini`` as shown below:
.. code-block:: ini
@ -245,14 +246,14 @@ cloud, neutron's policy file ``policy.yaml`` can be modified to allow this.
Modify ``/etc/neutron/policy.yaml`` entries as follows:
.. code-block:: none
.. code-block:: yaml
"get_loggable_resources": "rule:regular_user",
"create_log": "rule:regular_user",
"get_log": "rule:regular_user",
"get_logs": "rule:regular_user",
"update_log": "rule:regular_user",
"delete_log": "rule:regular_user",
"get_loggable_resources": "rule:regular_user"
"create_log": "rule:regular_user"
"get_log": "rule:regular_user"
"get_logs": "rule:regular_user"
"update_log": "rule:regular_user"
"delete_log": "rule:regular_user"
Service workflow for Operator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -406,8 +407,8 @@ The general characteristics of each event will be shown as the following:
* A timestamp of the flow.
* A status of the flow ``ACCEPT``/``DROP``.
* An indication of the originator of the flow, e.g which project or log resource
generated the events.
* An indication of the originator of the flow, e.g which project or log
resource generated the events.
* An identifier of the associated instance interface (neutron port id).
* A layer 2, 3 and 4 information (mac, address, port, protocol, etc).

4
doc/source/admin/config-ml2.rst
View File

@ -316,7 +316,9 @@ The ML2 plug-in also supports extension drivers that allows other pluggable
drivers to extend the core resources implemented in the ML2 plug-in
(``networks``, ``ports``, etc.). Examples of extension drivers include support
for QoS, port security, etc. For more details see the ``extension_drivers``
configuration option in the `Configuration Reference <../configuration/ml2-conf.html#ml2.extension_drivers>`__.
configuration option in the
`Configuration Reference
<../configuration/ml2-conf.html#ml2.extension_drivers>`__.
Agents

9
doc/source/admin/config-ndp-proxy.rst
View File

@ -83,10 +83,10 @@ To configure NDP proxy, take the following steps:
a single, integrated subnetpool. In order to make NDP proxy work correctly,
the admin operator needs to set direct routes for these subnetpools.
Such as, we have a IPv6 subnetpool, it's CIDR is 2001:db8::/96. The direct route
like below should be set:
Such as, we have a IPv6 subnetpool, it's CIDR is 2001:db8::/96. The direct
route like below should be set:
.. code-block:: none
.. code-block:: console
2001:db8::/96 dev <ext-gw>
@ -275,7 +275,8 @@ network (such as: public network) are the following:
:ref:`prefix-delegation` etc.) to publish the internal IPv6 address, the
command will break dataplane traffic.
#. Create an internal network and IPv6 subnet and add the subnet to the above router:
#. Create an internal network and IPv6 subnet and add the subnet to the above
router:
.. code-block:: console

6
doc/source/admin/config-ovs-offload.rst
View File

@ -75,7 +75,8 @@ Prerequisites
Using Open vSwitch hardware offloading
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to enable Open vSwitch hardware offloading, the following steps are required:
In order to enable Open vSwitch hardware offloading, the following steps are
required:
#. Enable SR-IOV
#. Configure NIC to switchdev mode (relevant Nodes)
@ -425,7 +426,8 @@ Validate Open vSwitch hardware offloading
.. end
#. Check traffic on the representor port. Verify that only the first ICMP packet appears.
#. Check traffic on the representor port. Verify that only the first ICMP
packet appears.
.. code-block:: console

25
doc/source/admin/config-ovsfwdriver.rst
View File

@ -82,18 +82,19 @@ Both OVS and iptables firewall drivers should always behave in the same way if
the same rules are configured for the security group. But in some cases that is
not true and there may be slight differences between those drivers.
+----------------------------------------+-----------------------+-----------------------+
| Case | OVS | iptables |
+========================================+=======================+=======================+
| Traffic marked as INVALID by conntrack | Blocked | Allowed because it |
| but matching some of the SG rules | | first matches SG rule,|
| (please check [1]_ and [2]_ | | never reaches rule to |
| for details) | | drop invalid packets |
+----------------------------------------+-----------------------+-----------------------+
| Multicast traffic sent in the group | Allowed always | Blocked, |
| 224.0.0.X | | Can be enabled by SG |
| (please check [3]_ for details) | | rule. |
+----------------------------------------+-----------------------+-----------------------+
+-------------------------------------+----------------+----------------------+
| Case | OVS | iptables |
+=====================================+================+======================+
| Traffic marked as INVALID by | Blocked | Allowed because it |
| conntrack but matching some of the | | first matches SG |
| SG rules (please check [1]_ and | | rule, never reaches |
| [2]_ for details) | | rule to drop invalid |
| | | packets |
+-------------------------------------+----------------+----------------------+
| Multicast traffic sent in the group | Allowed always | Blocked, |
| 224.0.0.X | | Can be enabled by SG |
| (please check [3]_ for details) | | rule. |
+-------------------------------------+----------------+----------------------+
Open Flow rules processing considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3
doc/source/admin/config-qos-min-bw.rst
View File

@ -172,7 +172,8 @@ In release Stein the following agent-based ML2 mechanism drivers are
supported:
* Open vSwitch (``openvswitch``) vnic_types: ``normal``, ``direct``
* SR-IOV (``sriovnicswitch``) vnic_types: ``direct``, ``macvtap``, ``direct-physical``
* SR-IOV (``sriovnicswitch``) vnic_types: ``direct``, ``macvtap``,
``direct-physical``
* OVN (``ovn``) vnic_types: ``normal``
.. note::

2
doc/source/admin/config-qos-min-pps.rst
View File

@ -230,7 +230,9 @@ with:
* :oslo.config:option:`ovs.resource_provider_packet_processing_without_direction`
Format for this option is ``<hypervisor>:<packet_rate>``. This option should
be used for non-hardware-offloaded OVS deployments.
* :oslo.config:option:`ovs.resource_provider_packet_processing_with_direction`
Format for this option is
``<hypervisor>:<egress_packet_rate>:<ingress_packet_rate>``. You may set only
one direction and omit the other. This option should be used for

17
doc/source/admin/config-qos.rst
View File

@ -40,7 +40,8 @@ QoS supported rule types are now available as ``VALID_RULE_TYPES`` in `QoS rule
* minimum_bandwidth: Minimum bandwidth constraints on certain types of traffic.
* minimum_packet_rate: Minimum packet rate constraints on certain types of traffic.
* minimum_packet_rate: Minimum packet rate constraints on certain types of
traffic.
Any QoS driver can claim support for some QoS rule types
@ -182,7 +183,7 @@ On the controller nodes:
#. Add the QoS service to the ``service_plugins`` setting in
``/etc/neutron/neutron.conf``. For example:
.. code-block:: none
.. code-block:: ini
service_plugins = router,metering,qos
@ -194,7 +195,7 @@ On the controller nodes:
set the ``service_plugins`` option in ``/etc/neutron/neutron.conf`` to
include both ``router`` and ``qos``. For example:
.. code-block:: none
.. code-block:: ini
service_plugins = router,qos
@ -321,7 +322,7 @@ your cloud, neutron's file ``policy.yaml`` can be modified to allow this.
Modify ``/etc/neutron/policy.yaml`` policy entries as follows:
.. code-block:: none
.. code-block:: yaml
"get_policy": "rule:regular_user"
"create_policy": "rule:regular_user"
@ -331,7 +332,7 @@ Modify ``/etc/neutron/policy.yaml`` policy entries as follows:
To enable bandwidth limit rule:
.. code-block:: none
.. code-block:: yaml
"get_policy_bandwidth_limit_rule": "rule:regular_user"
"create_policy_bandwidth_limit_rule": "rule:regular_user"
@ -340,7 +341,7 @@ To enable bandwidth limit rule:
To enable DSCP marking rule:
.. code-block:: none
.. code-block:: yaml
"get_policy_dscp_marking_rule": "rule:regular_user"
"create_policy_dscp_marking_rule": "rule:regular_user"
@ -349,7 +350,7 @@ To enable DSCP marking rule:
To enable minimum bandwidth rule:
.. code-block:: none
.. code-block:: yaml
"get_policy_minimum_bandwidth_rule": "rule:regular_user"
"create_policy_minimum_bandwidth_rule": "rule:regular_user"
@ -358,7 +359,7 @@ To enable minimum bandwidth rule:
To enable minimum packet rate rule:
.. code-block:: none
.. code-block:: yaml
"get_policy_minimum_packet_rate_rule": "rule:regular_user"
"create_policy_minimum_packet_rate_rule": "rule:regular_user"

3
doc/source/admin/config-rbac.rst
View File

@ -826,7 +826,8 @@ database following the next steps:
* Insert the indexes for the "target_tenant" and "action" columns:
$ for table in $tables do; mysql -e \
"alter table $table add key (action); alter table $table add key (target_tenant);"; done
"alter table $table add key (action); \
alter table $table add key (target_tenant);"; done
In order to prevent errors during a system upgrade, [3]_ was

10
doc/source/admin/config-services-agent.rst
View File

@ -111,11 +111,11 @@ To address this problem, operators should use the ``AGENT`` config group option
``kill_scripts_path`` to configure a path to where ``kill scripts`` for such
processes live. By default, it is set to ``/etc/neutron/kill_scripts/``.
If option ``kill_scripts_path`` is changed in the config to the different
location, ``exec_dirs`` in ``/etc/rootwrap.conf`` should be changed accordingly.
If ``kill_scripts_path`` is set, every time neutron has to kill a process,
for example ``dnsmasq``, it will look in this directory for a file with the name
``<process_name>-kill``. So for ``dnsmasq`` process it will look for a
``dnsmasq-kill`` script. If such a file exists there, it will be called
location, ``exec_dirs`` in ``/etc/rootwrap.conf`` should be changed
accordingly. If ``kill_scripts_path`` is set, every time neutron has to kill a
process, for example ``dnsmasq``, it will look in this directory for a file
with the name ``<process_name>-kill``. So for ``dnsmasq`` process it will look
for a ``dnsmasq-kill`` script. If such a file exists there, it will be called
instead of using the ``kill`` command.
Kill scripts are called with two parameters:

6
doc/source/admin/config-sfc.rst
View File

@ -323,9 +323,9 @@ Update a port chain or port pair group
SFC steers traffic matching the additional flow classifier to the
port pair groups in the port chain.
* Use the :command:`openstack sfc port pair group set` command to perform dynamic
scale-out or scale-in operations by adding or removing port pairs on a port
pair group.
* Use the :command:`openstack sfc port pair group set` command to perform
dynamic scale-out or scale-in operations by adding or removing port pairs
on a port pair group.
.. code-block:: console

56
doc/source/admin/config-sriov.rst
View File

@ -493,17 +493,17 @@ Once configuration is complete, you can launch instances with SR-IOV ports.
SR-IOV with ConnectX-3/ConnectX-3 Pro Dual Port Ethernet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In contrast to Mellanox newer generation NICs, ConnectX-3 family network adapters expose a single
PCI device (PF) in the system regardless of the number of physical ports.
When the device is **dual port** and SR-IOV is enabled and configured we can observe some inconsistencies
in linux networking subsystem.
In contrast to Mellanox newer generation NICs, ConnectX-3 family network
adapters expose a single PCI device (PF) in the system regardless of the number
of physical ports. When the device is **dual port** and SR-IOV is enabled and
configured we can observe some inconsistencies in linux networking subsystem.
.. note::
In the example below ``enp4s0`` represents PF net device associated with physical port 1 and
``enp4s0d1`` represents PF net device associated with physical port 2.
**Example:** A system with ConnectX-3 dual port device and a total of four VFs configured,
two VFs assigned to port one and two VFs assigned to port two.
**Example:** A system with ConnectX-3 dual port device and a total of four VFs
configured, two VFs assigned to port one and two VFs assigned to port two.
.. code-block:: console
@ -532,18 +532,20 @@ Four VFs are available in the system, however,
vf 2 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
vf 3 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
**ip** command identifies each PF associated net device as having four VFs *each*.
**ip** command identifies each PF associated net device as having four VFs
*each*.
.. note::
Mellanox ``mlx4`` driver allows *ip* commands to perform configuration of *all*
VFs from either PF associated network devices.
To allow neutron SR-IOV agent to properly identify the VFs that belong to the correct PF network device
(thus to the correct network port) Admin is required to provide the ``exclude_devices`` configuration option
in ``sriov_agent.ini``
To allow neutron SR-IOV agent to properly identify the VFs that belong to the
correct PF network device (thus to the correct network port) Admin is required
to provide the ``exclude_devices`` configuration option in ``sriov_agent.ini``
**Step 1**: derive the VF to Port mapping from mlx4 driver configuration file: ``/etc/modprobe.d/mlnx.conf`` or ``/etc/modprobe.d/mlx4.conf``
**Step 1**: derive the VF to Port mapping from mlx4 driver configuration file:
``/etc/modprobe.d/mlnx.conf`` or ``/etc/modprobe.d/mlx4.conf``
.. code-block:: console
@ -554,12 +556,15 @@ Where:
``num_vfs=n1,n2,n3`` - The driver will enable ``n1`` VFs on physical port 1,
``n2`` VFs on physical port 2 and
``n3`` dual port VFs (applies only to dual port HCA when all ports are Ethernet ports).
``n3`` dual port VFs (applies only to dual port HCA when all ports are
Ethernet ports).
``probe_vfs=m1,m2,m3`` - the driver probes ``m1`` single port VFs on physical port 1,
``probe_vfs=m1,m2,m3`` - the driver probes ``m1`` single port VFs on
physical port 1,
``m2`` single port VFs on physical port 2 (applies only if such a port exist)
``m3`` dual port VFs. Those VFs are attached to the hypervisor. (applies only if all ports are configured as Ethernet).
``m3`` dual port VFs. Those VFs are attached to the hypervisor. (applies only
if all ports are configured as Ethernet).
The VFs will be enumerated in the following order:
@ -575,7 +580,8 @@ In our example:
| 04:00.3 : VF associated to port **2**
| 04:00.4 : VF associated to port **2**
**Step 2:** Update ``exclude_devices`` configuration option in ``sriov_agent.ini`` with the correct mapping
**Step 2:** Update ``exclude_devices`` configuration option in
``sriov_agent.ini`` with the correct mapping
Each PF associated net device shall exclude the **other** port's VFs
@ -637,18 +643,20 @@ Known limitations
* SR-IOV is not integrated into the OpenStack Dashboard (horizon). Users must
use the CLI or API to configure SR-IOV interfaces.
* Live migration support has been added to the Libvirt Nova virt-driver in the Train
release for instances with neutron SR-IOV ports. Indirect mode SR-IOV interfaces
(vnic-type: macvtap or virtio-forwarder) can now be migrated transparently to
the guest. Direct mode SR-IOV interfaces (vnic-type: direct or direct-physical)
are detached before the migration and reattached after the migration so this is not
transparent to the guest. To avoid loss of network connectivy when live migrating
with direct mode sriov the user should create a failover bond in the guest with a
transparently live migration port type e.g. vnic-type normal or indirect mode SR-IOV.
* Live migration support has been added to the Libvirt Nova virt-driver in the
Train release for instances with neutron SR-IOV ports. Indirect mode SR-IOV
interfaces (vnic-type: macvtap or virtio-forwarder) can now be migrated
transparently to the guest. Direct mode SR-IOV interfaces (vnic-type: direct
or direct-physical) are detached before the migration and reattached after
the migration so this is not transparent to the guest. To avoid loss of
network connectivy when live migrating with direct mode sriov the user should
create a failover bond in the guest with a transparently live migration port
type e.g. vnic-type normal or indirect mode SR-IOV.
.. note::
SR-IOV features may require a specific NIC driver version, depending on the vendor.
Intel NICs, for example, require ixgbe version 4.4.6 or greater, and ixgbevf version
3.2.2 or greater.
* Attaching SR-IOV ports to existing servers is supported starting with the Victoria release.
* Attaching SR-IOV ports to existing servers is supported starting with the
Victoria release.

4
doc/source/admin/config-wsgi.rst
View File

@ -95,8 +95,8 @@ Create ``/etc/apache2/neutron.conf`` with content below:
.. end
For deb-based systems copy or symlink the file to ``/etc/apache2/sites-available``.
Then enable the neutron site:
For deb-based systems copy or symlink the file to
``/etc/apache2/sites-available``. Then enable the neutron site:
.. code-block:: console

2
doc/source/admin/deploy-lb-provider.rst
View File

@ -231,7 +231,7 @@ Create initial networks
Verify network operation
------------------------
.. include:: shared/deploy-provider-verifynetworkoperation.txt
.. include:: deploy-provider-verifynetworkoperation.txt
Network traffic flow
~~~~~~~~~~~~~~~~~~~~

2
doc/source/admin/deploy-lb-selfservice.rst
View File

@ -211,7 +211,7 @@ Create initial networks
Verify network operation
------------------------
.. include:: shared/deploy-selfservice-verifynetworkoperation.txt
.. include:: deploy-selfservice-verifynetworkoperation.txt
.. _deploy-lb-selfservice-networktrafficflow:

2
doc/source/admin/deploy-ovs-provider.rst
View File

@ -261,7 +261,7 @@ Create initial networks
Verify network operation
------------------------
.. include:: shared/deploy-provider-verifynetworkoperation.txt
.. include:: deploy-provider-verifynetworkoperation.txt
Network traffic flow
~~~~~~~~~~~~~~~~~~~~

2
doc/source/admin/deploy-ovs-selfservice.rst
View File

@ -207,7 +207,7 @@ Create initial networks
Verify network operation
------------------------
.. include:: shared/deploy-selfservice-verifynetworkoperation.txt
.. include:: deploy-selfservice-verifynetworkoperation.txt
.. _deploy-ovs-selfservice-networktrafficflow:

0
doc/source/admin/shared/deploy-provider-verifynetworkoperation.txt → doc/source/admin/deploy-provider-verifynetworkoperation.txt
View File

0
doc/source/admin/shared/deploy-selfservice-verifynetworkoperation.txt → doc/source/admin/deploy-selfservice-verifynetworkoperation.txt
View File

10
doc/source/admin/intro-os-networking.rst
View File

@ -236,11 +236,11 @@ filtering technology such as ``iptables``.
Each project contains a ``default`` security group that by default allows all
egress traffic and denies all ingress traffic. You can change the rules in the
``default`` security group. Admin user can also define own set of security group
rules which will be added by default to each new ``default`` and each new non
default (custom) security group created for every project in the cloud. There is
``security-group-default-rules`` API extension which allows to define such own
set of the default security group rules.
``default`` security group. Admin user can also define own set of security
group rules which will be added by default to each new ``default`` and each new
non-default (custom) security group created for every project in the cloud.
There is ``security-group-default-rules`` API extension which allows to define
such own set of the default security group rules.
If you launch an instance without specifying a security group, the ``default``
security group automatically applies to it. Similarly, if you create a port
without specifying a security group, the ``default`` security group

3
doc/source/admin/ovn/routing.rst
View File

@ -7,7 +7,8 @@ Routing
North/South
-----------
The different configurations are detailed in the :doc:`/admin/ovn/refarch/refarch`
The different configurations are detailed in the
:doc:`/admin/ovn/refarch/refarch`
Non distributed FIP
~~~~~~~~~~~~~~~~~~~

12
doc/source/admin/ovn/smartnic_dpu.rst
View File

@ -16,12 +16,12 @@ familiar with the following specifications
Overview
--------
A class of devices collectively referred to as off-path SmartNIC DPUs introduces
an important change to earlier architectures where compute and networking agents
used to coexist at the hypervisor host: networking control plane components
are now moved to the SmartNIC DPU's CPU side which includes ``ovs-vswitchd``
and ``ovn-controller``. The following diagram provides an overview of the
components involved::
A class of devices collectively referred to as off-path SmartNIC DPUs
introduces an important change to earlier architectures where compute and
networking agents used to coexist at the hypervisor host: networking control
plane components are now moved to the SmartNIC DPU's CPU side which includes
``ovs-vswitchd`` and ``ovn-controller``. The following diagram provides an
overview of the components involved::
┌────────────────────────────────────┐
│ Hypervisor │ LoM Ports

24
doc/source/admin/shared/deploy-secgrouprules.txt
View File

@ -10,7 +10,8 @@
| remote_ip_prefix | 0.0.0.0/0 |
+------------------+-----------+
$ openstack security group rule create --ethertype IPv6 --proto ipv6-icmp default
$ openstack security group rule create --ethertype IPv6 \
--proto ipv6-icmp default
+-----------+-----------+
| Field | Value |
+-----------+-----------+
@ -31,13 +32,14 @@
| remote_ip_prefix | 0.0.0.0/0 |
+------------------+-----------+
$ openstack security group rule create --ethertype IPv6 --proto tcp --dst-port 22 default
+------------------+-----------+
| Field | Value |
+------------------+-----------+
| direction | ingress |
| ethertype | IPv6 |
| port_range_max | 22 |
| port_range_min | 22 |
| protocol | tcp |
+------------------+-----------+
$ openstack security group rule create --ethertype IPv6 --proto tcp \
--dst-port 22 default
+----------------+---------+
| Field | Value |
+----------------+---------+
| direction | ingress |
| ethertype | IPv6 |
| port_range_max | 22 |
| port_range_min | 22 |
| protocol | tcp |
+----------------+---------+

36
doc/source/admin/shared/deploy-selfservice-initialnetworks.txt
View File

@ -42,7 +42,8 @@ NAT for IPv4 network traffic and directly routes IPv6 network traffic.
If you are using an MTU value on your network below 1280, please
read the warning listed in the
`IPv6 configuration guide <../config-ipv6.html#project-network-considerations>`__
`IPv6 configuration guide
<../config-ipv6.html#project-network-considerations>`__
before creating any subnets.
#. Create a IPv4 subnet on the self-service network.
@ -67,22 +68,23 @@ NAT for IPv4 network traffic and directly routes IPv6 network traffic.
.. code-block:: console
$ openstack subnet create --subnet-range fd00:192:0:2::/64 --ip-version 6 \
--ipv6-ra-mode slaac --ipv6-address-mode slaac --network selfservice1 \
--dns-nameserver 2001:4860:4860::8844 selfservice1-v6
+-------------------+------------------------------------------------------+
| Field | Value |
+-------------------+------------------------------------------------------+
| allocation_pools | fd00:192:0:2::2-fd00:192:0:2:ffff:ffff:ffff:ffff |
| cidr | fd00:192:0:2::/64 |
| dns_nameservers | 2001:4860:4860::8844 |
| enable_dhcp | True |
| gateway_ip | fd00:192:0:2::1 |
| ip_version | 6 |
| ipv6_address_mode | slaac |
| ipv6_ra_mode | slaac |
| name | selfservice1-v6 |
+-------------------+------------------------------------------------------+
$ openstack subnet create --subnet-range fd00:192:0:2::/64 \
--ip-version 6 --ipv6-ra-mode slaac --ipv6-address-mode slaac \
--network selfservice1 --dns-nameserver 2001:4860:4860::8844 \
selfservice1-v6
+-------------------+--------------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------------+
| allocation_pools | fd00:192:0:2::2-fd00:192:0:2:ffff:ffff:ffff:ffff |
| cidr | fd00:192:0:2::/64 |
| dns_nameservers | 2001:4860:4860::8844 |
| enable_dhcp | True |
| gateway_ip | fd00:192:0:2::1 |
| ip_version | 6 |
| ipv6_address_mode | slaac |
| ipv6_ra_mode | slaac |
| name | selfservice1-v6 |
+-------------------+--------------------------------------------------+
#. Create a router.

18
doc/source/admin/vpnaas-scenario.rst
View File

@ -25,7 +25,8 @@ they provide their version of manuals.
set suitable plugin for your own deployment.
#. Configure the VPNaaS service provider by creating the
``/etc/neutron/neutron_vpnaas.conf`` file as follows, ``strongswan`` used in Ubuntu distribution:
``/etc/neutron/neutron_vpnaas.conf`` file as follows, ``strongswan`` used
in Ubuntu distribution:
.. code-block:: ini
@ -41,7 +42,8 @@ they provide their version of manuals.
Consider to use the appropriate one for your deployment.
#. Configure the VPNaaS plugin for the L3 agent by adding to
``/etc/neutron/l3_agent.ini`` the following section, ``StrongSwanDriver`` used in Ubuntu distribution:
``/etc/neutron/l3_agent.ini`` the following section, ``StrongSwanDriver``
used in Ubuntu distribution:
.. code-block:: ini
@ -78,13 +80,13 @@ Using VPNaaS with endpoint group (recommended)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IPsec site-to-site connections will support multiple local subnets,
in addition to the current multiple peer CIDRs. The multiple local subnet feature
is triggered by not specifying a local subnet, when creating a VPN service.
Backwards compatibility is maintained with single local subnets, by providing
the subnet in the VPN service creation.
in addition to the current multiple peer CIDRs. The multiple local subnet
feature is triggered by not specifying a local subnet, when creating a VPN
service. Backwards compatibility is maintained with single local subnets, by
providing the subnet in the VPN service creation.
To support multiple local subnets, a new capability called "End Point Groups" has
been added. Each endpoint group will define one or more endpoints of
To support multiple local subnets, a new capability called "End Point Groups"
has been added. Each endpoint group will define one or more endpoints of
a specific type, and can be used to specify both local and peer endpoints for
IPsec connections. The endpoint groups separate the "what gets connected" from
the "how to connect" for a VPN service, and can be used for different flavors

30
doc/source/contributor/alembic_migrations.rst
View File

@ -319,7 +319,9 @@ Expand and Contract Scripts
The obsolete "branchless" design of a migration script included that it
indicates a specific "version" of the schema, and includes directives that
apply all necessary changes to the database at once. If we look for example at
the script ``2d2a8a565438_hierarchical_binding.py``, we will see::
the script ``2d2a8a565438_hierarchical_binding.py``, we will see:
.. code-block:: python
# .../alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
@ -351,20 +353,23 @@ the script ``2d2a8a565438_hierarchical_binding.py``, we will see::
# ... more DROP instructions ...
The above script contains directives that are both under the "expand"
and "contract" categories, as well as some data migrations. the ``op.create_table``
directive is an "expand"; it may be run safely while the old version of the
application still runs, as the old code simply doesn't look for this table.
and "contract" categories, as well as some data migrations.
The ``op.create_table`` directive is an "expand"; it may be run safely while
the old version of the application still runs, as the old code simply doesn't
look for this table.
The ``op.drop_constraint`` and ``op.drop_column`` directives are
"contract" directives (the drop column more so than the drop constraint); running
at least the ``op.drop_column`` directives means that the old version of the
application will fail, as it will attempt to access these columns which no longer
exist.
"contract" directives (the drop column more so than the drop constraint);
running at least the ``op.drop_column`` directives means that the old version
of the application will fail, as it will attempt to access these columns which
no longer exist.
The data migrations in this script are adding new
rows to the newly added ``ml2_port_binding_levels`` table.
Under the new migration script directory structure, the above script would be
stated as two scripts; an "expand" and a "contract" script::
stated as two scripts; an "expand" and a "contract" script:
.. code-block:: python
# expansion operations
# .../alembic_migrations/versions/liberty/expand/2bde560fc638_hierarchical_binding.py
@ -427,7 +432,9 @@ For such cases, we use the ``contract_creation_exceptions`` that should be
implemented as part of such migrations. This is needed to get functional tests
pass.
Usage::
Usage:
.. code-block:: python
def contract_creation_exceptions():
"""Docstring should explain why we allow such exception for contract
@ -445,7 +452,8 @@ HEAD files for conflict management
In directory ``neutron/db/migration/alembic_migrations/versions`` there are two
files, ``CONTRACT_HEAD`` and ``EXPAND_HEAD``. These files contain the ID of the
head revision in each branch. The purpose of these files is to validate the
revision timelines and prevent non-linear changes from entering the merge queue.
revision timelines and prevent non-linear changes from entering the merge
queue.
When you create a new migration script by neutron-db-manage these files will be
updated automatically. But if another migration script is merged while your

4
doc/source/contributor/client_command_extensions.rst
View File

@ -24,8 +24,8 @@
Client command extension support
================================
The client command extension adds support for extending the neutron client while
considering ease of creation.
The client command extension adds support for extending the neutron client
while considering ease of creation.
The full document can be found in the python-neutronclient repository:
https://docs.openstack.org/python-neutronclient/latest/contributor/client_command_extensions.html

48
doc/source/contributor/contribute.rst
View File

@ -142,10 +142,10 @@ code base.
potentially breaks your code. It is then up to you maintaining the affected
plugin/driver to determine whether the failure is transient or real, and
resolve the problem if it is.
* it communicates to a patch author that they may be breaking a plugin/driver.
If they have the time/energy/relationship with the maintainer of the
plugin/driver in question, then they can (at their discretion) work to
resolve the breakage.
* it communicates to a patch author that they may be breaking a
plugin/driver. If they have the time/energy/relationship with the
maintainer of the plugin/driver in question, then they can (at their
discretion) work to resolve the breakage.
* it communicates to the community at large whether a given plugin/driver
is being actively maintained.
* A maintainer that is perceived to be responsive to failures in their
@ -251,12 +251,14 @@ it does not affect Neutron core code stability.
DevStack Integration Strategies
-------------------------------
When developing and testing a new or existing plugin or driver, the aid provided
by DevStack is incredibly valuable: DevStack can help get all the software bits
installed, and configured correctly, and more importantly in a predictable way.
For DevStack integration there are a few options available, and they may or may not
make sense depending on whether you are contributing a new or existing plugin or
driver.
When developing and testing a new or existing plugin or driver, the aid
provided by DevStack is incredibly valuable: DevStack can help get all the
software bits installed, and configured correctly, and more importantly in a
predictable way.
For DevStack integration there are a few options available, and they may or
may not make sense depending on whether you are contributing a new or
existing plugin or driver.
If you are contributing a new plugin, the approach to choose should be based on
`Extras.d Hooks' externally hosted plugins
@ -290,15 +292,16 @@ find on http://docs.openstack.org/infra/manual/creators.html. They are meant to
be the bare minimum you have to complete in order to get you off the ground.
* Create a public repository: this can be a personal opendev.org repo or any
publicly available git repo, e.g. ``https://github.com/john-doe/foo.git``. This
would be a temporary buffer to be used to feed the one on opendev.org.
publicly available git repo, e.g. ``https://github.com/john-doe/foo.git``.
This would be a temporary buffer to be used to feed the one on opendev.org.
* Initialize the repository: if you are starting afresh, you may *optionally*
want to use cookiecutter to get a skeleton project. You can learn how to use
cookiecutter on https://opendev.org/openstack-dev/cookiecutter.
If you want to build the repository from an existing Neutron module, you may
want to skip this step now, build the history first (next step), and come back
here to initialize the remainder of the repository with other files being
generated by the cookiecutter (like tox.ini, setup.cfg, setup.py, etc.).
want to skip this step now, build the history first (next step), and come
back here to initialize the remainder of the repository with other files
being generated by the cookiecutter (like tox.ini, setup.cfg,
setup.py, etc.).
* Create a repository on opendev.org. For
this you need the help of the OpenStack infra team. It is worth noting that
you only get one shot at creating the repository on opendev.org. This
@ -328,8 +331,8 @@ Internationalization support
----------------------------
OpenStack is committed to broad international support.
Internationalization (I18n) is one of important areas to make OpenStack ubiquitous.
Each project is recommended to support i18n.
Internationalization (I18n) is one of important areas to make OpenStack
ubiquitous. Each project is recommended to support i18n.
This section describes how to set up translation support.
The description in this section uses the following variables:
@ -485,9 +488,9 @@ For example, for the ``networking-foo`` repo::
neutron.ml2.extension_drivers =
foo_ext = networking_foo.plugins.ml2.drivers.foo:FooExtensionDriver
* Note: It is advisable to include ``foo`` in the names of these entry points to
avoid conflicts with other third-party packages that may get installed in the
same environment.
* Note: It is advisable to include ``foo`` in the names of these entry points
to avoid conflicts with other third-party packages that may get installed in
the same environment.
API Extensions
@ -531,8 +534,9 @@ Interface (VIF) drivers for the reference implementations are defined in
``neutron/agent/linux/interface.py``. Third-party interface drivers shall be
defined in a similar location within their own repo.
The entry point for the interface driver is a Neutron config option. It is up to
the installer to configure this item in the ``[default]`` section. For example::
The entry point for the interface driver is a Neutron config option. It is up
to the installer to configure this item in the ``[default]`` section.
For example::
[default]
interface_driver = networking_foo.agent.linux.interface.FooInterfaceDriver

52
doc/source/contributor/contributing.rst
View File

@ -4,9 +4,9 @@ So You Want to Contribute...
For general information on contributing to OpenStack, please check out the
`contributor guide <https://docs.openstack.org/contributors/>`_ to get started.
It covers all the basics that are common to all OpenStack projects: the accounts
you need, the basics of interacting with our Gerrit review system, how we
communicate as a community, etc.
It covers all the basics that are common to all OpenStack projects: the
accounts you need, the basics of interacting with our Gerrit review system,
how we communicate as a community, etc.
Below will cover the more project specific information you need to get started
with Neutron.
@ -21,9 +21,9 @@ Communication
- Team Meeting:
This is general Neutron team meeting. The discussion in this meeting is about
all things related to the Neutron project, like community goals, progress with
blueprints, bugs, etc. There is also ``On Demand Agenda`` at the end of this
meeting, where anyone can add a topic to discuss with the Neutron team.
all things related to the Neutron project, like community goals, progress
with blueprints, bugs, etc. There is also ``On Demand Agenda`` at the end of
this meeting, where anyone can add a topic to discuss with the Neutron team.
- time: http://eavesdrop.openstack.org/#Neutron_Team_Meeting
- agenda: https://wiki.openstack.org/wiki/Network/Meetings
@ -47,9 +47,9 @@ Communication
Contacting the Core Team
~~~~~~~~~~~~~~~~~~~~~~~~~
.. This section should list the core team, their irc nicks, emails, timezones etc. If
all this info is maintained elsewhere (i.e. a wiki), you can link to that instead of
enumerating everyone here.
.. This section should list the core team, their irc nicks, emails, timezones
etc. If all this info is maintained elsewhere (i.e. a wiki), you can link
to that instead of enumerating everyone here.
The list of current Neutron core reviewers is available on `gerrit
<https://review.opendev.org/#/admin/groups/38,members>`_.
@ -68,14 +68,15 @@ RFE should be submitted as a Launchpad bug first (see section
:ref:`reporting_a_bug`). The title of RFE bug should starts with ``[RFE]`` tag.
Such RFEs need to be discussed and approved by the :ref:`Neutron drivers
team<drivers_team>`. In some cases an additional spec proposed to the `Neutron
specs <https://opendev.org/openstack/neutron-specs>`_ repo may be necessary. The
complete process is described in detail in :ref:`Blueprints
specs <https://opendev.org/openstack/neutron-specs>`_ repo may be necessary.
The complete process is described in detail in :ref:`Blueprints
guide<neutron_blueprints>`.
Task Tracking
~~~~~~~~~~~~~~
.. This section is about where you track tasks- launchpad? storyboard? is there more
than one launchpad project? what's the name of the project group in storyboard?
.. This section is about where you track tasks- launchpad? storyboard? is
there more than one launchpad project? What's the name of the project group
in storyboard?
We track our tasks in `Launchpad <https://bugs.launchpad.net/neutron>`__.
If you're looking for some smaller, easier work item to pick up and get started
@ -85,16 +86,16 @@ List of all official tags which Neutron team is using is available on
:ref:`bugs<neutron_bugs>`.
Every week, one of our team members is the :ref:`bug
deputy<neutron_bug_deputy>` and at the end of the week such person usually
sends report about new bugs to the mailing list openstack-discuss@lists.openstack.org
or talks about it on our team meeting. This is also good place to look for some
work to do.
sends report about new bugs to the mailing list
openstack-discuss@lists.openstack.org or talks about it on our team meeting.
This is also good place to look for some work to do.
.. _reporting_a_bug:
Reporting a Bug
~~~~~~~~~~~~~~~
.. Pretty self explanatory section, link directly to where people should report bugs for
your project.
.. Pretty self explanatory section, link directly to where people should
report bugs for your project.
You found an issue and want to make sure we are aware of it? You can do so on
`Launchpad <https://bugs.launchpad.net/neutron/+filebug>`__.
@ -103,9 +104,9 @@ More info about Launchpad usage can be found on `OpenStack docs page
Getting Your Patch Merged
~~~~~~~~~~~~~~~~~~~~~~~~~
.. This section should have info about what it takes to get something merged. Do
you require one or two +2's before +W? Do some of your repos require unit test
changes with all patches? etc.
.. This section should have info about what it takes to get something merged.
Do you require one or two +2's before +W? Do some of your repos require
unit test changes with all patches? etc.
All changes proposed to the Neutron or one of the Neutron stadium projects
require two +2 votes from Neutron core reviewers before one of the core
@ -127,16 +128,17 @@ Additionally to what is described in this guide, Neutron's PTL duties are:
- triage new RFEs and prepare `Neutron drivers team meeting
<http://eavesdrop.openstack.org/#Neutron_drivers_Meeting>`_,
- maintain list of the :ref:`stadium projects<neutron_stadium>` health - if each
project has gotten active team members and if it is following community and
Neutron's guidelines and goals,
- maintain list of the :ref:`stadium projects<neutron_stadium>` health - if
each project has gotten active team members and if it is following community
and Neutron's guidelines and goals,
- maintain list of the :ref:`stadium projects
lieutenants<subproject_lieutenants>` - check if those people are still active
in the projects, if their contact data are correct, maybe there is someone
new who is active in the stadium project and could be added to this list.
Over the past few years, the Neutron team has followed a mentoring approach for:
Over the past few years, the Neutron team has followed a mentoring
approach for:
- new contributors,
- potential new core reviewers,

3
doc/source/contributor/dashboards/index.rst
View File

@ -18,7 +18,8 @@ Useful dashboard definitions are found in ``dashboards`` directory.
Grafana Dashboards
------------------
Look for neutron and networking-* dashboard by names by going to the following link:
Look for neutron and networking-* dashboard by names by going to the following
link:
`Grafana <https://grafana.opendev.org/>`_

234
doc/source/contributor/effective_neutron.rst
View File

@ -34,8 +34,8 @@ By reading and collaboratively contributing to such a knowledge base, your
development and review cycle becomes shorter, because you will learn (and teach
to others after you) what to watch out for, and how to be proactive in order
to prevent negative feedback, minimize programming errors, writing better
tests, and so on and so forth...in a nutshell, how to become an effective Neutron
developer.
tests, and so on and so forth...in a nutshell, how to become an effective
Neutron developer.
The notes below are meant to be free-form and brief by design. They are not meant
to replace or duplicate `OpenStack documentation <http://docs.openstack.org>`_,
@ -57,7 +57,8 @@ Developing better software
Plugin development
~~~~~~~~~~~~~~~~~~
Document common pitfalls as well as good practices done during plugin development.
Document common pitfalls as well as good practices done during plugin
development.
* Use mixin classes as last resort. They can be a powerful tool to add behavior
but their strength is also a weakness, as they can introduce `unpredictable <https://review.opendev.org/#/c/121290/>`_
@ -75,23 +76,26 @@ Document common pitfalls as well as good practices done during plugin developmen
there is an agent on the other side of the message broker that interacts
with the server. Plugins may not rely on `agents <https://review.opendev.org/#/c/174020/>`_ at all.
* Be mindful of required capabilities when you develop plugin extensions. The
`Extension description <https://github.com/openstack/neutron/blob/b14c06b5/neutron/api/extensions.py#L122>`_ provides the ability to specify the list of required capabilities
`Extension description <https://github.com/openstack/neutron/blob/b14c06b5/neutron/api/extensions.py#L122>`_
provides the ability to specify the list of required capabilities
for the extension you are developing. By declaring this list, the server will
not start up if the requirements are not met, thus avoiding leading the system
to experience undetermined behavior at runtime.
not start up if the requirements are not met, thus avoiding leading the
system to experience undetermined behavior at runtime.
Database interaction
~~~~~~~~~~~~~~~~~~~~
Document common pitfalls as well as good practices done during database development.
Document common pitfalls as well as good practices done during database
development.