Change function call order in ovs_neutron_agent during the
creation or modification of a port, in order to fulfill the
VLAN OVS tag information in the "port" register before calling
the SG agent. This information is needed in some SG agent
implementations.
Martin Hickey [Wed, 21 Oct 2015 14:24:13 +0000 (15:24 +0100)]
Update neutron-debug to use stevedore aliases
Updating neutron-debug as it is importing interface driver classes
directly and not using the load_driver_interface method.
Also adds unit tests for the neutron-debug tool.
AKamyshnikova [Thu, 8 Oct 2015 15:18:21 +0000 (18:18 +0300)]
Per-branch HEAD files for conflict management
We have pep8 check for validation revisions, but it allows
outdated changes go into merge queue. To prevent this added
CONTRACT_HEAD, EXPAND_HEAD files.
Gary Kotton [Thu, 29 Oct 2015 14:40:05 +0000 (07:40 -0700)]
Removes the use of mutables as default args
Passing mutable objects as default args is a known Python pitfall.
We'd better avoid this. This commit changes mutable default args with
None, then use 'arg = arg or {}', 'arg = arg or []'. For unit code which
doesn't use the args , just set with None. This commit also adds hacking
check.
Kyle Mestery [Thu, 29 Oct 2015 01:00:24 +0000 (10:00 +0900)]
Add notes about stable merge requirements for sub-projects
It was pointed out the requirements around what is allowed to be merged
into stable Neutron sub-projects wasn't clear. This attempts to make
that a bit more refined so those who choose to participate in the Neutron
Stadium know these requirements.
Ryan Moats [Wed, 28 Oct 2015 16:01:28 +0000 (11:01 -0500)]
Log end of router updates for PD and delete branches
These execution branches call continue directly without
logging the end of the router update. This leads to
confusion about when the last router update finishes if
it is a delete or a PD update.
Change-Id: Id82e7374aa9336e0adea3042238f30f716208373 Signed-off-by: Ryan Moats <rmoats@us.ibm.com>
Closes-bug: #1511004
Neil Jerram [Wed, 2 Sep 2015 14:14:30 +0000 (15:14 +0100)]
DHCP agent: log when reloading allocations for a new VM port
This will help us to see more clearly if failing DHCP for a new VM -
as seen in failures such as the following traceback from [1] - is
caused by DHCP configuration being too slow, as suggested by the
referenced bug.
Traceback (most recent call last):
File "/home/aqua/tempest/tempest/test.py", line 125, in wrapper
return f(self, *func_args, **func_kwargs)
File "/home/aqua/tempest/tempest/scenario/test_server_basic_ops_38.py", line 105, in test_server_basicops
self.verify_ssh()
File "/home/aqua/tempest/tempest/scenario/test_server_basic_ops_38.py", line 95, in verify_ssh
private_key=self.keypair['private_key'])
File "/home/aqua/tempest/tempest/scenario/manager.py", line 310, in get_remote_client
linux_client.validate_authentication()
File "/home/aqua/tempest/tempest/common/utils/linux/remote_client.py", line 55, in validate_authentication
self.ssh_client.test_connection_auth()
File "/home/aqua/tempest/tempest/common/ssh.py", line 150, in test_connection_auth
connection = self._get_ssh_connection()
File "/home/aqua/tempest/tempest/common/ssh.py", line 87, in _get_ssh_connection
password=self.password)
tempest.exceptions.SSHTimeout: Connection to the 172.17.205.21 via SSH timed out.
User: cirros, Password: None
John Schwarz [Mon, 12 Oct 2015 13:54:17 +0000 (16:54 +0300)]
Support migrating of legacy routers to HA and back
This patch adds support for migration of legacy routers to HA and
vice-versa. This patch also:
1. Reverts I4171ab481e3943e0110bd9a300d965bbebe44871, which was used to
disable such migrations until support was inserted to the codebase.
2. Adds an exception to indicate that such migrations are only available
on routers that have their admin_state_up set to False.
Closes-Bug: #1365426
DocImpact (Handled in patch 233695)
Change-Id: Ie92f8033f47e1bf9ba6310373b3bfc9833317580
Paul Ward [Thu, 24 Sep 2015 19:52:28 +0000 (14:52 -0500)]
Better tolerate deleted OVS ports in OVS agent
This change will not force a resync in the case where a virtual machine is
deleted, and therefore its OVS port deleted, in between the time an RPC
call was made to get the devices and where we make the call to correlate
those devices to vif ports.
John Schwarz [Thu, 15 Oct 2015 14:34:01 +0000 (17:34 +0300)]
get_device_by_ip: don't fail if device was deleted
The function gets a list of all the devices that exists on the machine,
and then iterates on them one at a time in order to find the correct
device which holds the ip specified. However, if one of the devices was
in the mean time deleted, the code will raise an Exception. In the ovs
agent's case, this will cause it to not run at all (requiring a
restart).
Also, changes to a few tests of LinuxBridge were made because
linuxbridge doesn't check that cfg.CONF.VXLAN.local_ip is not empty
before using it (a bug, surely). Since it's out of scope of this patch
to fix this, workarounds were implemented to make sure the tests ignore
the option instead.
marios [Fri, 21 Nov 2014 12:20:54 +0000 (13:20 +0100)]
Adds base in-tree functional testing of the dhcp agent (OVS)
Adds some utility methods and a couple of base test cases that
can be added to. These first tests exercise the ovs driver (dnsmasq)
and so the code is organised accordingly - OVS specific test cases
are defined in a DHCPAgentOVSTestFramework
YAMAMOTO Takashi [Wed, 21 Oct 2015 04:54:06 +0000 (13:54 +0900)]
Fix _restore_local_vlan_map race
Local vlan mappings provisioned by _restore_local_vlan_map
might not be cleaned up properly if the corresponding ports are
removed before we enter the main loop.
This commit fixes the problem by making _restore_local_vlan_map
just record local vlan IDs and leave the rest of provisioning logic
to the main loop.
By returning the need for binding, the (no-op) port processing
is skipped in the main sync loop. In fact, the port is already
detected as deleted and avoiding going over it again will save
us one log message, and thus many, many, many, many bytes over
time in logs.openstack.org.
Kyle Mestery [Wed, 21 Oct 2015 17:43:58 +0000 (17:43 +0000)]
Clarify what gerrit repositories can target neutron-specs
It wasn't made clear by the existing documentation that we only want
neutron, neutron-fwaas, neutron-lbaas, and neutron-vpnaas repositories
to target specs at neutron-specs. This makes it 100% crystal clear.
Code Review / openstack-build / neutron-build.git / log