Add an item to the instructions on iptables to OVS
firewall migration that the admin should cleanup
any stale iptables rules after completion. It is
out of scope of our documents on how exactly an
adminstrator might do that.
Closes-bug: #1864374
Change-Id: Ie1bf6b82e57a00f61640a131a29d897a9cde4629
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
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>
Add link from segments extension doc to routed networks spec,
which explains the use case.
Trivialfix
Closes-bug: #1747028
Change-Id: I8af639bc44924582135d3cc94196b3c9b3ca4b5d
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
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
These are leftover from opendev migration and
without this fix the links results into Not Found.
Mainly need to use "src" in place of "tree" to
get these links working with opendev.org.
Also used git tags where line references are used
as branched references do not persist. And for line
references use #L in place of #n as that's where it
get's redirected.
Also update references for zuul and use of
devstack-vm-gate-wrap.sh in neutron functional jobs.
Change-Id: I92d11c99a17dab80d4b91da49f341f9ba202bcfe
This patch implements support for CRUD operations for QoS minimum
packet rate, for example:
DELETE /qos/policies/$POLICY_ID/minimum_packet_rate_rules/$RULE_ID
Placement or dataplane enforcement is not implemented yet.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ie994bdab62bab33737f25287e568519c782dea9a
The quota driver ``ConfDriver`` was deprecated in Liberty release.
``NullQuotaDriver`` is created for testing although it could be used
in production if no quota enforcement is needed. However, because
the Quota engine is not plugable (is an extension always loaded), it
could be interesting to make it plugable as any other plugin.
This patch also creates a Quota engine driver API class that should be
used in any Quota engine driver. Currently it is used in the three
in-tree drivers implemented: ``NullQuotaDriver``, ``DbQuotaDriver``
and ``DbQuotaNoLockDriver``.
Change-Id: Ib4af80e18fac52b9f68f26c84a215415e63c2822
Closes-Bug: #1928211
Prior to this patch, the metadata agent was writing into SB
database when a network had been provisioned with metadata
on a particular chassis.
Then, neutron-server would wait for that event to happen with
a 15s timeout before sending the vif-plugged event to Nova.
By removing this mechanism:
1) We'll save writes to OVN SB database which, in highly loaded
systems and at scale reduces significantly the load on ovsdb-server.
2) Ignoring healthchecks (that still requires write to the SB DB),
we can make OVN metadata agent to connect to slave instances when
using active-backup OVN databases since writes are not needed.
3) There's a chance that the VM boots very fast and requests
metadata before the service is ready but since the timeout was
15 seconds, we can safely rely on the the cloud-init retries.
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
Change-Id: Ia6cd7a9a3b9662a9a8ce106e01a93c357c255956
This new quota driver, ``DbQuotaNoLockDriver``, does not create a lock
per (resource, project_id) but retrieves the instant (resource,
project_id) usage and the current (resource, project_id) reservations.
If the requested number of resources fit the available quota, a new
``Reservation`` register is created with the amount of units requested.
All those operations are done inside a DB transaction context. That
means the amount of resources and reservations is guaranteed inside
this transaction (depending on the DB backend isolation level defined)
and the new reservation created will not clash with other DB transation.
That will guarantee the number of resources and instant reservations
never exceed the quota limits defined for this (resource, project_id).
NOTES:
- This change tries to be as unobtrusive as possible. The new driver
uses the same ``DbQuotaDriver`` dabatase tables (except for
``QuotaUsage``) and the same Quota engine API, located in
``neutron.quota``. However, the Quota engine resources implements some
particular API actions like "dirty", that are not used in the new
driver.
- The Pecan Quota enforcement hooks,
``neutron.pecan_wgsi.hooks.quota_enforcement``, execute actions like
"resync", "mark_resources_dirty" or "set_resources_dirty", that has
no meaning in the new driver.
- The isolation between the Quota engine and the Pecan hook, and the
driver itself is not clearly defined. A refactor of the Quota engine,
Quota service, Quota drivers and a common API between the driver and
the engine is needed.
- If ``DbQuotaDriver`` is deprecated, ``CountableResource`` and
``TrackedResource`` will be joined in a single class. This resource
class will have a count method (countable) or a hard dependency on a
database table (tracked resource). The only difference will be the
"count" method implementation.
Closes-Bug: #1926787
Change-Id: I4f98c6fcd781459fd7150aff426d19c7fdfa98c1
This is patchset 1 of 2 for OVN driver handling of security-group-logging.
It includes the design documentation for this feature.
Changed a few lines in doc/source/admin/ovn/features.rst, so the extensions
are sorted in alphabetical order.
Related-Bug: 1914757
Partially-implements: https://review.opendev.org/c/openstack/neutron-specs/+/203509
Change-Id: I95d57613cef3b6892d3a0dd5705e2e8f3386a3a2
Before that patch it was possible to send ICMPv6 packets like e.g.
neutron_lib.constants.ICMPV6_TYPE_MLD_QUERY,
neutron_lib.constants.ICMPV6_TYPE_RS,
neutron_lib.constants.ICMPV6_TYPE_NS,
neutron_lib.constants.ICMPV6_TYPE_NA
And that could cause some security issues as instance could advertise
that it owns IPv6 address which really don't belong to it.
Now rules in table=71 which allows that traffic are "per mac/ipaddress"
and are allowed only for fixed ips allocated to port and port's
allowed_address_pairs.
Closes-Bug: #1902917
Change-Id: I4749fdc6a6cabd253b971bf4010ff76f5593c59c
Tell something about the config option ``explicitly_egress_direct``
since there is something not so much clear for users now.
Change-Id: I1c046d8140f93d9a8cd9e0bc43d3494e4f6a1ce7
With the new engine facade in place, a context session can execute
one single transaction at once. Nested transactions are no longer
supported.
This patch also changes db related examples in the "retries" document
that they uses engine facade.
Partially-Implements blueprint: enginefacade-switch
Change-Id: I978a24c3b30c2bb0a3ea6aa25ebf91ca5c58b8c9
Co-authored-by: Slawek Kaplonski <skaplons@redhat.com>
As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.
Also replace policy.json to policy.yaml ref from doc and tests.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: I0dbb8484e749e645627756e88ec79c1b26a6414a
This patch implements the last code bits pending to
conclude the new DB engine facade migration.
Due to the resultant interactions in the modified code, is
not possible to submit smaller patches; this code must be
migrated at once.
Partially-Implements blueprint: enginefacade-switch
Signed-off-by: Slawek Kaplonski <skaplons@redhat.com>
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: Id3f09b78c8d0a8daa7ec4fa6f5bf79f7d5ab8f8b
Using veth to interconnect openvswitch bridges was deprecated
in Victoria cycle. Now it's time to remove it from the code.
In neutron-ovs-agent code, there is still kept piece of code which
migrates from the veth to the patch ports for bridges interconnection.
We will be able to remove that piece of code in X release.
Change-Id: I94545c3c3d9be46ac2062691f69663e5e59cd648
Closes-Bug: #1587296
This reverts commit b8be1a05fa.
As was reported in bug [1] this patch broke multicast traffic send
from ports with disabled port security. And that broke L3HA routers
as keepalived processes couldn't talk to each other.
During attempt to fix that issue with keepalived we found out another
corner cases which we may break and in fact to fix them, we would
effectively revert this change and allow multicast traffic for all
ports in e.g. networks with ports which have port security and ports
which don't have port security and are on same node.
As we also don't really know what other corner cases we may hit going
further with that, lets revert this patch.
As a follow up patch I will propose new patch which will document
differences in handling multicast traffic between iptables and
openvswitch based firewall drivers.
[1] https://bugs.launchpad.net/neutron/+bug/1899967
Change-Id: I37a8b33cf8e16d5bb5dc1966fc2dca6bb619026c
Closes-Bug: #1899967
By default, if any multicast traffic sent to 224.0.0.X is allowed
in the OVS firewall (that means there is a specific egress rule),
this traffic is sent, in table 73 (ACCEPT_OR_INGRESS_TABLE), to
a rule with action NORMAL.
As commented in the related bug, https://tools.ietf.org/html/rfc4541,
chapter 2.1.2, section (2):
"Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports."
That means those packets will be forwarded to all ports regardless of
any ingress rule. This patch process this traffic separately, sending
those packets to table 102 (MCAST_RULES_INGRESS_TABLE). In this table
the ingress rules that have a defined protocol, will have an Open Flow
rule to output the traffic directly to those ports associated to this
rule.
For example, in the problem reported in the related bug, the VRRP
protocol (112), will be sent only to those ports that have this
ingress rule.
Change-Id: Ie271de144f78e364d938731ec9f5297e1a9d73f9
Closes-Bug: #1889631
Move port_forwarding.rst to doc/source/contributor/internals/ovn
Also, keep lines from the document no longer than 80 chars.
Change-Id: I2887eb022b268763193f93a68a32a4a0deaad42b