select router with subnet's gateway_ip for floatingip
1) when a subnet is connected to multiple routers and
all these routers are connected to same external network,
then select the router with subnet's gateway_ip, if available,
for managing floatingip.
2) Otherwise go with default existing behavior i.e
select first router in internal subnet, that also present on external network.
For scenario 1), if the router with gateway ip not selected,
then for connections initiated by external agent towards floatingip
won't get response with floatingip as source address,
instead gw ip of router(i.e router with subnet's gateway_ip) as source.
Details about the bug at [1]
lb: Correct String formatting to get rid of logged ValueError
The following error is caused by a missing String formatting in the
linuxbridge agent:
"ValueError: unsupported format character 'a' (0x61) at index 90
Logged from file linuxbridge_neutron_agent.py, line 447"
In addition a duplicated word in the log text has been fixed.
Assaf Muller [Mon, 7 Dec 2015 22:36:06 +0000 (17:36 -0500)]
Don't emit confusing error in netns-cleanup
If we're trying to delete a dhcp/qrouter device with use_veth
= False (Which is the default for some time), we'll first
try to 'ip link del %s', which will fail and emit a confusing
error, then try 'ovs-vsctl del-port'. There's no need to
log an error in such a case.
The patch attempts to future proof by setting the
set_log_fail_as_error(False) to be as tight as possible, so we
do log errors in case the device is somehow used in the future.
Monty Taylor [Sat, 5 Dec 2015 05:14:52 +0000 (00:14 -0500)]
Use keystoneauth instead of keystoneclient
keystoneauth was split out last cycle as a library specifically to deal
with doing auth functions so that people who do not need to do keystone
CRUD operations can just consume only the auth session parts. As part
of modernizing keystone interactions, use keystoneauth instead of
keystoneclient.
Assaf Muller [Sat, 5 Dec 2015 22:17:13 +0000 (17:17 -0500)]
Tox: Remove fullstack env, keep only dsvm-fullstack
In the functional tests we have 'functional' and 'dsvm-functional'
venvs. The difference is that dsvm-functional requires can run
rootwrap commands on the machine. In the fullstack context,
not running rootwrap commands doesn't make sense, as fullstack
tests are explicitly and solely integration tests.
Matt Riedemann [Fri, 20 Nov 2015 02:43:07 +0000 (18:43 -0800)]
Set timetable for removal of oslo.messaging.notify.drivers
Icehouse is dead and gone, at least upstream. These special driver
registrations are not tested in the gate-tempest-dsvm-neutron-full job
which means they are also not tested in requirements constraints jobs.
oslo.messaging 2.6.0 broke these already by removing the internal modules,
which was fixed in o.m 3.0.0 with (deprecated) alias modules.
The minimum required version of o.m in mitaka is currently greater than
2.6.1, so we're OK to remove these once stable/mitaka is our oldest
supported branch. So add a TODO to remove these once liberty-eol happens.
Proper configuration for notification drivers happens through the
config file using the oslo_messaging options:
The configuration options come from oslo and the server
executable is usually wrapped in a service script, supplied
by packagers and/or deployment tools. Any extra documentation
available in tree is of relative value, and the fact that
this file has been virtually ignored ever since it was
added is a testament of that.
Let's stop its agony and wish it to rest in peace.
Henry Gessau [Sun, 22 Nov 2015 02:39:35 +0000 (21:39 -0500)]
Final decomposition of the nuage plugin
This removes what's left of the nuage code and artifacts from the
neutron tree. All the vendor code is now in the
nuagenetworks/nuage-openstack-neutron repo on github.
rossella [Mon, 23 Nov 2015 12:53:45 +0000 (12:53 +0000)]
Add a script to create review dashboard for a milestone
This script queries launchpad to get:
1) Bug number of bugs tagged with rfe-approved
2) Bug number of critical/high bugs
3) list of blueprints targeted for the milestone passed as param
With this information the scripts prints queries that can be used
in Gerrit directly and creates a .dash file that can be used by
gerrit-dash-creator to output a dashboard url.
Victor Laza [Fri, 4 Dec 2015 09:11:23 +0000 (11:11 +0200)]
Remove Neutron core static example configuration files - addition
Change id Ic7ae2e038b5bd7b215c65c9c565bfe31ef551520 is incomplete,
the files had to be removed from setup.cfg also.
It beaks the HyperV-CI beacause the config files do not exist
anymore.
This patch adds the availability_zone support for router.
APIImpact
DocImpact: Make router scheduler availability zone aware. If multiple
availability zones are used, set router_scheduler_driver =
neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This scheduler
selects agent depends on LeastRoutersScheduler logic within an availability
zone so that considers the weight of agent.
Kevin Benton [Thu, 3 Dec 2015 01:55:01 +0000 (17:55 -0800)]
Fix default RBAC policy quota
The previous config value for the default RBAC policy
was not in neutron.conf and value that was registered
as a config option 'rbac_entry' didn't match the resource
name 'rbac_policy' so the default did not take effect.
This patch corrects it by registering the 'rbac_policy'
option instead of 'rbac_entry' and documents it in neutron.conf.
It also adds an API test that exercises the quota limit and
ensures that it's not set to -1.
Mike Bayer [Thu, 3 Dec 2015 19:21:13 +0000 (14:21 -0500)]
Run NOT NULL alterations before foreign key adds
The "migrate resources table" migration will fail
for some MariaDB versions if the NOT NULL alteration
is applied after the foreign key constraint has been
added [1]. This patch reverses the order so that
NOT NULL is applied first.
Oleg Bondarev [Thu, 3 Dec 2015 14:39:20 +0000 (17:39 +0300)]
Do not autoreschedule routers if l3 agent is back online
If there are a lot of routers scheduled to l3 agent,
rescheduling all of them one by one might take quite a long
period of time - during that time some agents might get back
online. In this case we should skip rescheduling.
Ryan Moats [Tue, 21 Jul 2015 21:52:56 +0000 (16:52 -0500)]
Add instrumentation devref, Part I
Presents what instrumentation is available from VIFs in Nova,
Metering Lables and Rules, Linux Bridge, and OVS. Proposes
mappings for structures defined in RFC 2863 and RFC 4293 and
the method that will be followed for a data collection proof
of concept.
How to aggregate and consume these counters will be covered
in future patch sets that extend this devref.
Gary Kotton [Thu, 26 Nov 2015 13:12:53 +0000 (05:12 -0800)]
Hyper-V: remove driver from the neutron tree
The hyperv drivers and code should be part of the networking-hyperv
project (https://github.com/openstack/networking-hyperv).
A few changes are necessary in order to prevent Hyper-V deployments from
breaking, especially when upgrading to Mitaka.
Hyper-V deployments are configured to use the in-branch HyperVSecurityGroupsDriver.
Removing it will cause the Hyper-V Neutron Agent to fail. If the agent is
configured to use the old driver, the networking_hyperv's driver must be used
instead and the users must be warned to update their configuration files to
use the networking_hyperv's security groups driver.
Removes the neutron-hyperv-agent entry point from setup.cfg.
Removes the hyperv mechanism_driver from setup.cfg
Moves the in-tree HyperVSecurityGroupsDriver to the networking_hyperv equivalent.
Logs a warning if the in-tree HyperVSecurityGroupsDriver is used.
Removes pywin32 and wmi requirements, as they've been included in networking_hyperv
and they are Hyper-V specific requirements.
Adds release note regarding the deprecated security groups driver.
Kevin Benton [Wed, 2 Dec 2015 23:35:00 +0000 (15:35 -0800)]
Make port binding message on dead agents clear
The previous message was misleading because it made it
sound like port binding was being attempted even though
the agent is dead. However, the actual logic is that
binding will be completely skipped if the agent is dead.
This patch updates the message to make that clear and also
provides the port ID as part of the warning so operators
without debugging enabled can see which ports failed.
Oleg Bondarev [Tue, 1 Dec 2015 08:47:05 +0000 (11:47 +0300)]
Notify about port create/update unconditionally
The notification about port create/update should be done no matter
if host (or any other field) was changed or not - it should be up to
handler to decide how to handle it.
This also fixes the bug when there was actually no notification to l3
dvr agent on compute node on new port creation:
_get_host_port_if_changed() always returned None - this is a regression
from commit 2ee08c3464c53abaf9bc5493132ad7958611e3b8
Doug Wiegley [Wed, 25 Nov 2015 23:46:19 +0000 (15:46 -0800)]
Move i18n to _i18n, as per oslo_i18n guidelines
- This does NOT break other projects that rely on neutron.i18n,
as this change includes a debtcollector shim to maintain those
older entry points, until they can migrate.
- Also updates _i18n.py to the latest pattern defined by oslo_i18n
- Guidance and template are from the reference:
http://docs.openstack.org/developer/oslo.i18n/usage.html
Oleg Bondarev [Wed, 25 Nov 2015 12:14:18 +0000 (15:14 +0300)]
DVR:don't reschedule the l3 agent running on compute node
For a DVR router, when it updates router gateway_ip, it should not
reschedule the l3 agents running on compute nodes whose mode is dvr,
it just need to reschedule the l3 agents running on network nodes
whose mode is dvr_snat.
Code Review / openstack-build / neutron-build.git / log