The nova_metadata_ip config for the metadata daemon has to point
to the SERVICE_HOST (controller) instead of HOST_IP (the host
Also the service_metadata_proxy True has to be set along with
the n-api-metadata service (not n-cpu), so the nova-metadata server
will see the setting.
Right now we're starting metadata agent passing in neutron and ml2
config files. In multinode environments we can't assume that those
files will be present in compute nodes so this patch is adding the
necessary parameters to metadata config file so that it doesn't
depend on any more files.
* Use oslo-config-generator config file to generate ml2_conf.ini.
This can be used by oslo_config sphinxext in a follow-up patch.
* Generate metadata_agent.ini sample automatically.
Previously metadata_agent.ini was maintained manually.
* Update .gitignore not to ignore etc directory.
I see no good reason not to maintain etc directory in the repo.
* Update devstack plugin to ensure the output directory
where the ml2_conf sample file will be generated.
Preparation for auto-generated config reference
as part of doc-migration community-wide effort.
Changes in the mechanism driver:
* Automatically create a port with device_owner=network:dhcp to
serve metadata and eventually DHCP.
* Auto-allocate an IP for the metadata port on subnet creation.
* Push static route for 169.254.169.254 in DHCP options.
* Wait until metadata service is provisioned in the chassis where
a port resides before sending the event to Nova.
* Implementation of .
* Starts networking-ovn-agent with the proper config files.
* Disables config drive in nova.conf for tempest against master
* Enables TEMPEST_RUN_VALIDATION for tempest against master branch.
In order to test this patch out we need to make these changes to
* [DEFAULT] section:
force_config_drive = False
* [neutron] section:
service_metadata_proxy = True
This patch depends on  and  (already merged into OVS master).
NOTE: Metadata tests are only enabled for the non-voting tempest job
which runs against OVS master branch. The release job runs against
OVS 2.7 which doesn't include  so those tests are disabled
until OVS 2.8 is released.
This patch is extending the DevStack plugin to allow installing ovsdbapp
from git master branch. This will be used in the ovsdbapp gate to run
the latest code against networking-ovn to ensure that changes made to
the ovsdbapp library won't break the project.
Networking-ovn gate failed for ovn-controller service error.
Use absolute path command and pass user as a parameter to run_process
Another problem is regarding the commit
d0c961a99f570ec1973bf5540ba9237b6720c848 from OVS that removed the
run, log, and db directories as part of the normal `make install`
process. These directories were expected to be in place, so this patch
is manually creating them before the DevStack module for networking-ovn
tries to set some permissions on them.
Co-Authored-By: Lucas Alvares Gomes <email@example.com>
Adapt new QoS driver to fix devstack failure.
Override test_floatingip_update_subnet_gateway_disabled to fix unit
Change mapping_dict.keys() to list(mapping_dict.keys()) in
_get_chassis_physnets to fix python3.5 dsvm functional test
Both the L3 and DHCP agents are no longer supported. Remove many more
remnants from when they were supported.
Signed-off-by: Russell Bryant <firstname.lastname@example.org>
After kernel updated, kernel devel-lib was updated as well, generated
makefile in OVS became stale, that using unstack.sh and then stack.sh
can't re-compile new OVS kernel module.
Add "sudo make distclean" to cleanup_ovn to wipe generated makefile.
Signed-off-by: Dong Jun <email@example.com>
This is a patch for supporting distributed NAT with centralized NAT rules
in networking-ovn native L3 routing.
Remove transit network
Support scheduling gateway port by setting redirect-chassis
Support gateway sNAT
Support gateway default route
Support floating IP
Support full sync including sNAT, gateway route and floating IP
Unit tests of syncing sNAT and FIP
Gratuitous ARP for sNAT and FIP
Signed-off-by: Dong Jun <firstname.lastname@example.org>
Co-authored-by: Guoshuai Li <email@example.com>
Caused by this ovs commit:
To improve security, the NB and SB ovsdb daemons no longer
have open ptcp connections by default. This is a change in
behavior from previous versions, users wishing to use TCP
connections to the NB/SB daemons can either request that
a passive TCP connection be used via ovn-ctl command-line
options (e.g. via OVN_CTL_OPTS/OVN_NORTHD_OPTS in startup
Thus add option to devstack:
Signed-off-by: Dong Jun <firstname.lastname@example.org>
This commit introduces the NAT support for networking-ovn. The proposal for
NAT support can be found @ 
1. Add functional test cases (To be followed up in a different patch)
2. Add sync code (Opened a bug to track this)
3. Add unit tests for the new ovsdb APIs (Opened a bug to track this)
The new multinode experimental gate job  requires the subnode to
be configured properly as a compute node running the OVN controller.
An incorrect environment variable is used while waiting for ovn-northd
to start. As a result, the test was successful even though ovn-northd
wasn't started. This may cause the subsequent ovs-appctl command to fail
and thus the DevStack deployment to fail. We've seen this periodically
in the gate.
The DHCP agent logs in the gate-tempest-dsvm-networking-ovn job
see numerous key errors as reported in bug 1624079. These errors
appear to be related to setting the DHCP agent force_metadata
or enable_isolated_metadata configuration options to True.
These key errors may be related to the recent instability of the
gate-tempest-dsvm-networking-ovn job. While bug 1624079 is being
fixed, we will only force the DHCP agent to handle metadata when
native OVN L3 is enabled.
The vtep-gw sets up vxlan tunnels to other chassis only if
the encapsulations they support includes vxlan.
For the vagrant vtep-gw testbed, configure vxlan as a
supported encap by default.
OVN native L3 and DHCP don't provide metadata support so config drive
must be used when both are enabled. However, if the conventional DHCP
agent is enabled it can be configured to provide metadata support.
This patch set provides the necessary DevStack and Vagrant deployment
fixes to properly configure DHCP and metadata support. In addition,
documentation and release notes have been updated accordingly. And
finally, the q-meta service was removed from devstackgatekuryrrc,
since the gate job is setup for OVN native services.
Co-Authored-By: Matt Kassawara <email@example.com>
Fail deployment if both q-dhcp and OVN_NATIVE_DHCP are enabled. Such
deployments introduce unnecessary neutron DHCP provisioning blocks
and still don't provide DHCP metadata proxy support.
Because the native services gate job sets ipv6 forwarding settings,
we stop accepting RAs from IPv6-only host environments. This leads
to a loss of external connectivity, which is bad for zuul running
tests and stuff.
Setting accept_ra to 2 will cause the RAs to be accepted.
This fix is based on .
Support install the ovs python module from ovs source. This can
be used to test and validate new ovs python features. This should
only be used for development purposes since the ovs python version
is controlled by OpenStack requirements.
Co-Authored-By: Numan Siddique <firstname.lastname@example.org>
OVN has added a new DHC_Options table in OVN NB DB to define
DHCP options. Logical Switch ports refer to this table if
DHCP is to be enabled.
This patch creates rows for DHCP_Options for each of the
subnets and adds the reference to the ports when created.
If extra DHCP options are defined for a port, a new
DHCP_Options row is created for the port.
This patch provides the infrastructure for the OVN L3 to schedule
the router gateway port. The OVN hypervisor administrator can
set aside certain hypervisors to be used for scheduling router
gateway ports. This is the corresponding WIP patch at the moment:
For now it is assumed that any hypervisor/chassis can host a router
There are 2 types of schedulers defined at the moment
The Chassis (add/delete/update) event is used to schedule router
gateway ports which have not been bound to any chassis.
A future patch will add functional tests.
A recent DevStack change  broke the networking-ovn gate. The
change is being reverted  to unbreak the gate. However, the
change found a weakness in the OVN provider network setup. In
particular when Q_USE_PROVIDERNET_FOR_PUBLIC=True, the
networking-ovn DevStack plugin should setup the bridge and
bridge mapping like it does when Q_USE_PROVIDER_NETWORKING=True.
The vagrant deployment broke in a different way because
PHYSICAL_NETWORK was not set (which is used to set the
flat networks supported). To fix this, the vagrant deployment
will now use the networking-ovn DevStack plugin for basic
provider network setup.
The tunnel overhead calculation now accounts for the IP overhead.
See  for details. As a result, the networking OVN ML2 driver's
geneve max_header_size default configuration is 20 bytes too large
since it included the IPv4 overhead. This patch set takes advantage
of  and allows the IP overhead to be calculated by ML2.
Rework previous fix for gate failures  based on review
comments. Instead of overriding the neutron-ovs-cleanup command,
this fix will copy the applicable OVS bridge setup functions
from DevStack with the neutron-ovs-cleanup command removed.
When we write a grenade plugin, we need most of the functions
in plugin.sh. Hence moving the functions to a library, it will
enable both the plugin functionalities to operate on the same library.