The DNS ordering and OVN DHCP documents were out-of-date
and using the old neutronclient, updated.
Noticed while fixing an openstackclient bug related to
dns_nameservers ordering.
TrivialFix
Related-bug: #2053201
Change-Id: Iab15750a4adc8dc78d839f0a1b952f9d87bdab8a
A non-vlan-transparent trunk parent port (tpt) should only forward
untagged frames. Earlier it was configured to forward anything (trunk
mode in ovs). This patch changes the trunk mode to access mode and
sets the trunk parent's tag explicitly to 0.
Change-Id: I4bcfe53fe87d7c9218dd0db9d7224bb323709a21
Closes-Bug: #2048785
Current translation no longer use babel[1] or these setup.cfg
entries[2].
[1] 4e907ed2f39329eaa12d1712d49ca8903db15124
[2] 22df2f6395c1426485a7cb97166601823f8a2a28
Change-Id: Ic866a41b00c37c549a83274e33ac18d0aba846bb
Over time docs were added or updated such that they were
no longer in alphabetical order based on the index order
or their title strings. Tried to fix it up a bit along
with some capitalization.
Trivialfix
Change-Id: I948b2a1c86faaffed07adcf0198a3fba72401abe
I found some old graphs I have drawn about the workings of the
traditional metadata service. I don't know why I haven't contributed
this earlier to Neutron docs. But anyway, better late than never.
Change-Id: I7a412883c8c0d673d1617a3b212598b35e9e698f
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>
Now this job runs on 3 nodes:
* 1 main, controller and networker like, without nova-compute service on
it, this node has "dvr_snat" set as L3 agent's mode,
* 2 compute like nodes with nova compute and L3 agent in "dvr" mode
Even though there is only one "dvr_snat" node in the job, it keeps
"l3_ha" option set to "true" in Neutron's config. That way we are still
testing "ha" code path of the centralized part of the router but also
job is now closer to the real life, and supported deployments topology.
Additionally this patch adds nodeset for 3 nodes with Ubuntu Jammy and
controller node not running compute service as there is no such nodeset
defined globally.
Related-Bug: #1934666
Change-Id: Id6a91795ebc73be26bb34d9eaf8a53b2b6a1ba0c
Add link from segments extension doc to routed networks spec,
which explains the use case.
Trivialfix
Closes-bug: #1747028
Change-Id: I8af639bc44924582135d3cc94196b3c9b3ca4b5d
When trying to execute the fullstack tests, I was a little bit lost in
the documentation.
This change is a proposal to refactor this a little bit so the only
source of truth is the doc/source/contributor/testing/fullstack.rst
file.
Change-Id: Ibaf2ab9a227d71d18adf027d2ae509168c1e26da
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
This was discussed during the October 2022 PTG in the Neutron room.
Even if we do have many Neutron jobs which inherits from the
"tempest-integrated-networking" job, we are overriding some
configuration of that base job in our repo.
To make sure that we are not breaking any other projects we should run
in our check and gate queues directly "tempest-integrated-networking"
job too as this is our "reference" job from the integrated CI used by
other projects.
To avoid redundancy in CI jobs this patch also removes
"neutron-ovn-tempest-ovs-release" from the check queue and moves it back
to the experimental queue.
Change-Id: I00e5248ed816618d2132b502a7116626f9c59dc5
Column with python's version used in the job was useful when we had
both py2.7 and py3 jobs. But now we supports only Python 3 so this
column is not needed anymore (and also it was outdates as we don't use
python 3.6 anymore in master branch).
Change-Id: I49cfeca1d454af9fb6379227d2aebac3da3709e1
We had 2 different kinds of "ovn ipv6 only" jobs defined:
- neutron-ovn-tempest-ovs-release-ipv6-only
- neutron-ovn-tempest-ipv6-only
First of them was running only smoke tempest tests and we had it
in our periodic queue.
Second was run in the check and gate queues and was running all tempest
networking related tests.
That second one was also installing OVS and OVN from sources instead of
the packages provided by the distro.
This patch unifies those 2 jobs so we now have
abstract "neutron-ovn-tempest-ipv6-only-base" and derived from that
2 different jobs:
- neutron-ovn-tempest-ipv6-only-ovs-release - used in check/gate queue,
- neutron-ovn-tempest-ipv6-only-ovs-master - used in periodic queue
Additionally this patch removes "neutron-ovn-tempest-ovs-release" job
from the periodic queue as it is now in the check/gate queue.
Change-Id: I355c5eaca31e12bf980794b1867e1ca39aea96e0
This job was run only in periodic queue until now but to avoid issues
like described in the related but, we should have this job run in
the check/gate queues as this is job which almost directly inherits from
the "tempest-integrated-networking" defined in the tempest.
Related-Bug: #1991962
Change-Id: I0ceaa9667a9218cb12a0f3b666a68d4bddeb6911
Bullet points shouldn't be preceded by a space. Doing so renders them as
blockquotes. We also have a load of literals/code. Mark them as such.
Change-Id: I59c09c88a68f617f03a1753332ffb5311f8806a6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
A new script to remove the duplicated port bindings was added. This
script will list all ``ml2_port_bindings`` records in the database,
finding those ones with the same port ID. Then the script removes
those ones with status=INACTIVE. This script is useful to remove
those leftovers that remain in the database after a failed live
migration.
"dry_run" mode is possible if selected in "[cli_script] dry_run"
boolean config option. The duplicated port bindings are printed in
the shell but not deleted.
Related-Bug: #1979072
Change-Id: I0de5fbb70eb852f82bd311616557985d1ce89bbf
This reverts commit bce27811df.
Reason for revert: neutron-fwaas has maintainers so the documentation should be available.
Due to changes since the original deletion commit the following changes
were added:
* Add note that OVN is not yet supported
* Remove note that Horizon support is not available
Change-Id: I1a739ee045b49e9b44283c28f95b1accc8a1e37f
It has been suggested in the Neutron CI meeting to include a section in
the documentation advicing against blind rechecks. It turns out that
such section already exists. What this change does is to move the
section to the first level of the contributors guide, to make it more
visible. This change also improves some wording and adds some examples
of proper recheck comments.
Change-Id: Ib0a00d13a28f98b0a0f26c7233365d04453db4e0
Noticed a typo while reading the docs, fixed other grammatical
issues while I was here.
Trivial-fix
Change-Id: I9d62281e095688bcbcb1fbab3d1cd5101ae7ad37
Added support for filtering the QoS rule type list command.
Two new filter flags are added:
- all_supported: if True, the listing call will print all QoS rule
types supported by at least one loaded mechanism driver.
- all_rules: if True, the listing call will print all QoS rule types
supported by the Neutron server.
Both filter flags are exclusive and not required.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/827533
Closes-Bug: #1959749
Change-Id: I41eaab177e121316c3daec34b309c266e2f81979
Table 59 will be used for pps limitation, the pipeline change is:
all original flows with ``goto table 60`` will be changed to
``goto table 59``, while table 59 has a default rule is goto
table 60. Then we can add pps flows to table 59 for all ports.
Basic limit pipeline is:
Ingress: packets get into br-int table 0, before send to table 60,
in table 59, check the destanation MAC and local_vlan ID, if the
dest is resident in this host, do the meter pps action and send
to table 60.
Egress: match src MAC and in_port, before send to table 60,
in table 59, do the meter pps action and send to table 60.
Why table 59? Because for ovs-agent flow structure, all packets
will be send to table 60 to do next actions such as security group.
Between table 0 and table 60, there are tables for ARP poison/spoofing
prevention rules and MAC spoof filtering. We want similar security
checks to take effect first, so it can drop packets before filling
our limit queues (pps limitation based on data forwarding queue).
And we do not want packets go through the long march of security group
flows, in case of performance side effect when there are large amount
of packets try to send, so limit it before goto security group flows.
Partially-Implements: bp/packet-rate-limit
Related-Bug: #1938966
Related-Bug: #1912460
Change-Id: I943f610c3b6bcf05e2e752ca3b57981f523f88a8