Occurances of Openstack (incorrect capitalization) are replaced with
OpenStack
Change-Id: I7f33060a2dd430cdd49aebf9420e3cd54d21c72c
Closes-Bug: #1535246
None of the L2populationDbMixin methods actually use 'self' for
anything. As the class is basically just used as a namespace and
modules already provide that, this patch gets rid of the mixin. This
makes the code simpler and easier to debug as inheritance doesn't buy
us anything in this case.
Change-Id: Ibf4dfe49a2ebc32d3909d3d7b579d2bb2ea3f61d
The OPNFV project [1] is a reference implementation of the
ETSI NFV architecture built on open source components.
OpenStack, and Neutron in particular, are key elements of
this story, and many requirements and issues are driven and
submitted by OPNFV folks that work in both communities.
This tag makes sure that we can keep all of them together for
tracking purposes.
[1] http://superuser.openstack.org/articles/openstack-and-opnfv-strengthen-collaboration-for-telcos
Change-Id: Ie1675ef6f177558f579097fe035494b9380232d0
The discussion in [2] indicated that [1] would lead to orphaned
items during error cases. This refactoring replaces the
optimistic approach followed by [1] with a separate delete code
path that does not execute the operations that take place within
the namespace that will be removed. Operations that take place
outside of those namespaces are still performed to ensure that
no orphaned items result.
A comment has been added to the functional test to explain what
case is being tested.
[1] https://review.openstack.org/#/c/240971
[2] conversation starting at http://goo.gl/bZgvqW
Change-Id: I663f1264fb3963789b79a4a7c3e46d232b2f0620
Signed-off-by: Ryan Moats <rmoats@us.ibm.com>
Initially, we bumped the required version for the agent endpoint from
1.1 (the initial version that implemented security groups) to 1.3
without considering that the code should work with old agents that do
not yet know about the new devices_to_update argument.
Actually, there was no need to bump the version: old agent side code
already captures all unknown arguments that could be passed from the
server, ignoring them:
608b54137f/neutron/agent/securitygroups_rpc.py (L155)
(^ the link shows the latest Kilo code as of writing)
Note: some people may argue that the approach that is taken in Neutron
to support backwards compatibility for server notifications is wrong,
and we instead should adopt some stricter mechanism like nova version
pinning. While that is a noble thing to do, it's out of scope for the
patch that is designed to be easily backportable to stable/liberty.
Note: some people may also argue that the patch should go straight into
stable/liberty because we don't claim support for rolling upgrade
scenarios that span multiple releases. That's indeed true, though my
take on it is that if we have a way to handle more unofficial scenarios
without more coding effort, it's worth doing it.
Change-Id: I741e6e5c460658ac17095551040e67e8d1990812
Closes-Bug: #1531772
When we remove explicit binding of dvr routers to compute nodes
we'll need a way to know all hosts where a dvr router should be
hosted in order to send notifications.
This patch adds such a query and updates l3 rpc notifier to use it.
Partially implements blueprint improve-dvr-l3-agent-binding
Change-Id: Ic6680bb42455189f14c4c913b1d4adeebda83180
get_ha_sync_data_for_host will call _get_dvr_sync_data
even given agent is not in DVR agent_mode.
_get_dvr_sync_data has additional processing for dvr
like:
dvr_router_ids = set(router['id'] for router in routers
if is_distributed_router(router))
floating_ip_port_ids = [fip['port_id'] for fip in floating_ips
if fip['router_id'] in dvr_router_ids]
which should only work for DVR scenario.
That will increase neutron-server processing time for
non-DVR scenario. Adding logic to judge whether given
agent is in DVR agent_mode, call get_sync_data directly.
Closes-Bug: #1510796
Change-Id: I5572e19b7cd8b2ea63fde4463705ab1c56fe5e68
DHCP agent may be used by plugins that don't set mtu value for networks.
Handle the case by not passing the DHCP option when network does not
have the value set.
Most plugins do set the value though, since it's enforced in base db
plugin class.
Closes-Bug: #1534197
Change-Id: I282b3d6b81f91eb8cea901d955cbcca6ecb2a95d
Even though we have a duplicate IP check before creating an IP
allocation, there is a window between when that check is completed
and when the record is committed to the database. During this window,
another thread or server may use the same IP address, which will result
in the database commit failing with a DBDuplicateEntry exception.
This patch adds a decorator to convert the exception into a
RetryRequest, which will be caught at the API layer to start the
operation over, at which point the normal duplicate check will find
the IP and return the correct error to the user.
This was done instead of trying to convert the DBDuplicate to the
correct exception since it's on commit and there are possibly many
different sources of the duplicate record beyond the IP allocation
(depending on what mechanism drivers did during pre-commit, etc).
By retrying the request, we ensure that the prechecks run again that
will raise the appropriate exception.
Change-Id: I37a964497bf60a61bc49bdeec94a008f167c384f
Closes-Bug: #1534447
