This patch is adding support for a new port type called "external" in
core OVN.
Prior to this work, when a VM had a SR-IOV port attached to it, OVN itself
wasn't able to reply to things such as DHCP requests packets since the
OVS port was skipped. Core OVN then introduced the concept of "external"
ports which are ports deployed on a different node than the one that the
VM is running and is able to reply to such requests on behalf of the VM.
With this patch, when a port with the VNIC type "direct" and no
"switchdev" capability is created, ovn driver will then create a
logical port with the type "external" for it and add it to a default
HA Chassis Group. The port will then get bound to the "master" (higher
priority) chassis of that group.
Please note that, as a first step, this patch is creating only one HA
Chassis Group which *all* external ports will belong to. That means that
all external ports will be *scheduled onto the same node* (but it's
HA nevertheless). In the future we should enhance this behavior.
Change-Id: Ic6c4bb6c584682169f3ebd73105a847b05dddc76
Closes-Bug: #1841154
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
test_dnsmasq_version() is sometimes triggering a traceback
because the new dnsmasq_enable_addr6_list config option isn't
being found. Register the option in the test class.
Change-Id: Ie441f831bcd0835ae8e1cd082005640b65b7393a
Closes-bug: #1866129
In local dev environments devstack may be configured to clone
a component from a git repo with a working directory, for example:
$HOME/src/ovn/.git
The original logic took the the base name without the .git extension
as the repo name to use - for this path that is the empty string,
which of course did not work.
This change supplies a meaningful default repo name for cases like this.
Change-Id: I3a2796f67d7f0634b1f25d44f4fa229d31ef9cc1
The sanity checks related to neutron-server config only make sense
when q-svc service is enabled. When building a devstack without q-svc
(for example a compute-only devstack) do not force this configuration
to be present where it's meaningless.
Change-Id: I5b9176d4a55a826f498e367f1f02569429dbe546
... to q-ovn-metadata-agent.
To the best of my understanding we decided to keep using the
neutron-legacy devstack module since it is the one used in the gate:
http://lists.openstack.org/pipermail/openstack-discuss/2019-December/thread.html#11544
And we merge new features like the ovn migration only working with
neutron-legacy:
https://review.opendev.org/696592
It seems to me we were a bit inconsistent in naming devstack service
'neutron-ovn-metadata-agent' since legacy style devstack service
names start with 'q-'.
For example this sample config is broken:
https://opendev.org/openstack/neutron/src/branch/master/devstack/ovn-compute-local.conf.sample#L31-L35
stack.sh dies with:
lib/neutron: line 368: neutron_plugin_create_nova_conf: command not found
Because not having a single 'q-' service in that enabled service list
we trip up devstack's 'is_neutron_legacy_enabled' check:
e51cbf0ea9/lib/neutron (L127-L135)
This change renames devstack service neutron-ovn-metadata-agent
to q-ovn-metadata-agent.
I'm not proud to propose this change in 2020 (circa 5 years after
the rename from Quantum to Neutron) so let me know if you see a better
way. :-)
Change-Id: I507a3426e2b63bff49891bd5a51fa9d9999a0ffa
This patch is ading IGMP snooping support in the OVN driver. Multicast
support has been introduced in core OVN upstream.
Also, the patch always sets the "mcast_flood_unregistered" config in
the OVN Logical_Switch to the same value as the "mcast_snoop" config.
This is so that OVN matches the OVS behavior which is to enable IGMP
flooding by default [0] (in OVN, by default it's false).
[0] http://www.openvswitch.org/support/dist-docs/ovs-vsctl.8.txt (grep
for "mcast-snooping-disable")
Change-Id: I32f61ba3dd06d7eacf76a74c5c44e1286f90e584
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Adds a new bool option dnsmasq_enable_addr6_list, when
enabled configuration for dnsmasq will be created with a
single dhcp-host entry specifying a list of ip addresses
allocated for a port.
Previously the dnsmasq dhcp-agent driver would write a
separate dhcp-host entry for each fixed-ip of a port in
the dnsmasq hosts file. The result of the previous
behaviour is that dnsmasq will only use one of the config
entries, i.e the first one matching the mac identifier.
The trade-off is that only a single dns_assignment will
be used for IPv6 addresses within the same subnet. (But
in practice, this was always the case since only the
first config entry would be used by dnsmasq.)
Why is this neccecary:
This is done to enable ironic provisioning over IPv6
using DHCPv6-stateful. For background info, please
read dnsmasq-discuss thread:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/thread.html#13671
Closes-Bug: #1861032
Change-Id: I833840e7daed2efa7efaece27cfd1ba28e0feb90
When reading the 'neutron-keepalived-state-change' log, if an error
occurs, provide in the error log the namespace devices and addresses.
Change-Id: Ia324b2cf40cb72d28efdc8826c673ec9395d3a24
Closes-Bug: #1865557
If a user specifies a header in their request for metadata,
it could override what the proxy would have inserted on their
behalf. Make sure to remove any headers we don't want, and
override something that might be present in the request.
If the agent somehow gets a request with both headers it will
silently drop it.
Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6
Closes-bug: #1865036
We will soon have different version for OVN and OVS, this patch is
splitting the OVN_BRANCH and OVS_BRANCH variables in the DevStack
module.
Change-Id: Icf32d168d177268afeb02c95084543d97f4f07e6
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
mock.assert_called_once is valid method since Python 3.6
but it's not allowed to use it in neutron because of
outdated flake8 check.
Change-Id: I8cdcc0e32618613472139ad9094bb19d562d6426
This patch adds some tests to be blacklisted in
neutron-ovn-tempest-slow because of already known bugs.
Change-Id: I78606f33fcd8f0f4b179dc9d2b71cb9afb8b4880
Sometimes we had a situation, where Logical_Switch_Port type
received by IDL had a different type, that type set in the
NBDB. We changed the way we retrieve the LS from DB, to not
loop over rows in table, but call db_find_rows() instead.
With this change after about 40 retries of functional tests we
don't spot the same issue again.
Change-Id: I07c081d1984b26a10a4d854d17117cfeaac7f8ac
Related-Bug: 1862618
- This change fixed an issue where the update_router_routes method
would not execute when all static routes were removed
Closes-Bug: #1860273
Change-Id: I33559947f63ab4259ec99f093350e8e6eeb83d7d
Signed-off-by: zhangyuhe <1073258077@qq.com>
During processing of security group rule list API call Neutron will
now ensure that default security group for project given in the filters
or in the context exists.
It is similar to what is done for list of security groups or creation of
new network/port in the project.
Change-Id: Id6fee5a752968b356b884d939b708a420016c9bc
Closes-Bug: #1864171