The migration script "delete-neutron-resources" was being
executed on controller-0 instead of the undercloud node regardless
of the defer_to:localhost ansible setting.
In that controller ~/overcloudrc does not exist, so the cleanup
was failing silently.
This commit moves the cleanup to a separate role that we tie
to localhost (undercloud) from ovn-migration.yml
Closes-Bug: #1804194
Change-Id: I05f2411604ba01d170440ac655491a624f98aafc
The commands used by constraints need at least tox 2.0. Update to
reflect reality, which should help with local running of constraints
targets.
Change-Id: Ib137f4f5243a71f302116aa83a4662d1cc8a89ed
Closes-Bug: #1801461
It was noticed that sometimes the functional tests are timing out or
passing but very close to reaching the maximum timeout (which prior to
this patch was set to 120), for example:
2018-10-24 11:26:41.149 | {4}
networking_ovn.tests.functional.test_ovn_db_sync.TestOvnNbSync.test_ovn_nb_sync_log
[112.504775s] ... ok
2018-10-24 11:26:41.151 | {5}
networking_ovn.tests.functional.test_ovn_db_sync.TestOvnNbSync.test_ovn_nb_sync_off
[107.899102s] ... ok
2018-10-24 11:26:41.154 | {6}
networking_ovn.tests.functional.test_ovn_db_sync.TestOvnNbSyncOverTcp.test_ovn_nb_sync_log
[113.171442s] ... ok
This patch is bumping this maximum timeout from 120 to 240 to give these
tests a better chance of finishing whatever they have are testing.
It's important to remember that the VMs testing the code in the
OpenStack gate runs on shared hosts so, depending on how busy these
hosts are at the moment of the tests the same test can take more or less
time than usually.
Closes-bug: #1799703
Change-Id: I06c7c91dffc9d1c5768ec156a54b0c1b0ab21d4f
This patch adds support for UDP protocol. It however also introduces
a limitation. Currently OVN flows are configured such that LBs can
support only a single protocol. Therefore, an LB can be configured
to use only UDP or only TCP.
The protocol in the LB is set by the FIRST Listener associated with
it.
This patch allows pools to also have UDP protocol.
Partial-Bug: #1789157
Change-Id: I1fa13dfbd165f470bfc0b83222bdec36edf70f94
This patch is changing the test_metadata_agent_healthcheck to allow
some time (up to 5 seconds) for expected SB config value to be
propagated.
Prior to this patch, it was checked straight away and sometimes it
it didn't match the expected value.
Change-Id: Ia5308cda75571b624f84efa83cffe2acdc04f097
Related-Bug: #1719574
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Because of [1], when a controller is disconnected and you add a new
port to an Open vSwitch bridge ovs-vswitchd crashes.
There's a patch upstream, but this will allow us to continue
without
Closes-Bug: #1798377
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1640045
Change-Id: Id47086d50167fd417d0be67b720f63be62e3ff35
OVN requires the subnet information while creating members,
so that it can track the references to a network. Without the
subnet, members should not be created when OVN is the provider driver
for Octavia
Change-Id: I7f9ef5ae53f64279e70d83510ec51f24cd264fc2
This patch adds the support for updating the DB during
Cascade deletion for LBs. Currently, the flows are deleted but
the status of the entities connected with the LBs are not cleared,
thus causing an uneven status in the DB.
Change-Id: I31da7134d51665bbfe316b8a05cc34216420a4d0
Closes-Bug: #1793759
With moving away from required milestone releases, the version numbers
calculated by PBR on the master branch will not work for those testing
upgrades from the last stable release. More details can be found in the
mailing list post here:
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135706.html
This is an empty commit that will cause PBR to increment its calculated
version to get around this.
PBR will see the following which will cause it to increment the version:
Sem-Ver: feature
Please merge this patch as soon as possible to support those testing
upgrades.
Change-Id: Iad3c4ee758cb04f65cc18f0d604076b31d7b5222
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The agent_alive() method may fail with a unhandled KeyError when it
tries to determine whether an agent that has been already deleted from
the AgentStats tracker is alive or not.
This patch handles the problem and in those cases it will just report
the agent as "dead".
Closes-Bug: #1796878
Change-Id: Ieee97721af09474fbbd4f03ab74da409f1e12833
If port groups are supported, the sync script will still create
address sets and ACLs based on the old implementation.
This patch is taking into account whether Port Groups are supported
and create the right resources accordingly.
Closes-Bug: #1798028
Change-Id: I529d82b28be9bb93649f19034027c41ee1aff08b
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
When deploying multinode environments with devstack using sample
config files, all nodes were eligible to host a gateway but normally
only one would have external connectivity. This would lead to
some gateways being unreachable.
This patch is setting the 'enable-chassis-as-gw' in the default
sample file and leave it disabled in the compute one. This way,
gateways will be scheduled only on master nodes where external
connectivity is assumed.
Change-Id: I3671b2cd57daa0bc2851a287e6cd88c142b45e41
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
This patch fixes wrong path which prevents doc from being correctly
built.
Change-Id: I865da811157aa41bf0c7f1cf1089b93cb373707e
Closes-Bug: #1795883
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
The migration to port groups task is now moved to the maintenance
worker. This worker holds a distributed lock within OVSDB so we'll
make sure that the migration will be performed just once.
During an update/upgrade, it may happen that newer version of
neutron-server can't migrate to Port Groups as the lock is held
by other (old instance). When all servers have been updated, the
maintenance task will perform the migration just once on the cloud
making sure that normal operation will happen.
We can remove this task in later cycles as this is just a migration
path from Address Sets to Port Groups for implementing Neutron
Security Groups.
TODO: functional test to validate the migration path to PGs.
Change-Id: I227ec967f450b26b12f19d687e94029e6ef1e558
Closes-Bug: #1789921
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Currently it seems that when Listener is created before pool creation,
the pool is not updated correctly in the NBDB leading to loss of VIPs
as the workflow continues.
Also updated the dict to deepcopy to ensure that ovn_lb's external_ids
dict is not directly modified as it seems to be held by Python's memory
context which prevented updation of Pool in the listener's key-value pair
in OVN LB.
Also removed a trivial line which was written by dude.
Closes-Bug: #1792317
Change-Id: Ibb4d6a47fdaede4ccd04125bb55ead3ae31112ab
As part of the Denver PTG [1] we decided networking related projects
that are "current" and want to receive neutron-lib consumption patches
on an on-going basis should indicate such with a well defined comment
in their requirements.txt. This allows us to easily find the list of
project to receive neutron-lib consumption patches [2] by searching for
the string.
In addition, projects opting-in for these patches are also attesting
they will stay up to date with TC and infra initiatives to ensure
consumption patches can flow freely.
This patch adds the "neutron-lib-current" string to requirements.txt
opting in for neutron-lib consumption patches.
[1] https://etherpad.openstack.org/p/neutron-stein-ptg
[2] https://docs.openstack.org/neutron-lib/latest/contributor/contributing.html#phase-4-consume
Change-Id: I0e2e759be5dfebdd9267b48662d361e4950fdd1c
This patch registers and lists the OVN metadata agent with Neutron.
Since the OVN Controller / Gateway use the Chassis UUID as its own
agent UUID, the OVN Metadata creates can't re-use that. Instead, this
patch generates a random UUID for each Metadata agent and saves it to the
external_ids' column in the Chassis table. At startup time, the metadata
agent will check if the "neutron:ovn-metadata-id" key is present in the
Chassis external_id column and use that UUID if it's there, otherwise
it will generate a random UUID for it.
This patch uses the same AgentStats mechanism to identify whether the
OVN metadata agent is alive or not by relying on the "nb_cfg" from the
Chassis. The only difference from the OVN controller agent is that the
metadata will save the "nb_cfg" of it's last update into the Chassis
external_ids column.
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Closes-Bug: #1719574
Change-Id: Icfc9e76e8371d8f33b264df65ae3a7cbc0ca099e
Instead of returning the immediate status, mimick ML2/OVS's
agent_down_time handling. With this patch, we no longer have an
issue where an agent will appear down because we didn't wait long
enough for ovn-controller to update the Chassis and we don't have
to wait before sending a response to API requests.
Closes-Bug: #1719574
Change-Id: Ib08473e4768c94ad3b0a223b72f1dad1d26769dd
The OVS command checking the router port revision number was
accidentally removed from the update_router_port() method. This patch is
re-adding it.
Change-Id: I4ce8f9219afdcf5c74dad144ce05af9dba283d07
Closes-Bug: #1792593
This patch is changing the default Python interpreter in the tempest
jobs to Python3, affecting the following playbooks:
* tempest-dsvm-networking-ovn-ovs-master
* tempest-dsvm-networking-ovn-ovs-relase
The patch also introduces a new python2 tempest job running against the
released version of OVS for testing backward compatibility with the old
python interpreter.
There was a tempest-dsvm-networking-ovn-ovs-master-python3 job
definition that ran in the experiemental gate pipeline that has been
deleted as part of this change as well. We don't need it anymore.
Change-Id: Ifc053c03ad08dd373d7dc0afadf860c848b386c9
The driver was relying on attributes such as "im_class" that does not
exist in Python3+ anymore.
This patch fixes those problems and also add a new job in the gate to
exercise tempest with Python3.5+ so those errors don't sneak in the
code again.
Closes-Bug: #1791925
Change-Id: I8686288bd4493f56b25e99281999bdd5e1296f8c
When using distributed floating IPs, we set the external MAC
address and logical port fields regardless whether the LSP
is up. For the particular use of Octavia LB VIP, which doesn't
ever get bound, the floating IP associated to it will never
get the flows installed by ovn-controller.
This patch changes the mechanism so that the DNAT entries get
updated only on port up/down changes. If the port remains
down, the external_mac will be cleared and traffic to those
FIPs will still go through the centralized router.
When a port gets bound to a chassis, if DVR is enabled, the
mac_address field will be populated and traffic will go to
the compute node.
Closes-bug: #1789686
Change-Id: I0043984b4bb7b3780112aba170ffb956c48084d0
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
This patch is dropping the code that creates and handles the
subnet Port Groups. Those were used to place the ACLs that
allowed DHCP traffic to reach the responder in the OVN
pipeline but as explained in the bug description, it's
not needed anymore.
Change-Id: I30bee5c5576554b162e66e1b5dfbe734522ab363
Closes-Bug: #1790900
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Miguel Angel Ajo