Kevin Benton [Wed, 26 Aug 2015 05:03:27 +0000 (22:03 -0700)]
Stop device_owner from being set to 'network:*'
This patch adjusts the FieldCheck class in the policy engine to
allow a regex rule. It then leverages that to prevent users from
setting the device_owner field to anything that starts with
'network:' on networks which they do not own.
This policy adjustment is necessary because any ports with a
device_owner that starts with 'network:' will not have any security
group rules applied because it is assumed they are trusted network
devices (e.g. router ports, DHCP ports, etc). These security rules
include the anti-spoofing protection for DHCP, IPv6 ICMP messages,
and IP headers.
Without this policy adjustment, tenants can abuse this trust when
connected to a shared network with other tenants by setting their
VM port's device_owner field to 'network:<anything>' and hijack other
tenants' traffic via DHCP spoofing or MAC/IP spoofing.
Retry metadata request on connection refused error
This testcase may fail intermittently on 'Connection refused' error.
This could be due to the fact that the metadata proxy setup is not exactly
complete at the time the request is issued; in fact there is no
synchronization between the router being up and the metadata request being
issued, and clearly this may be the reason of accidental but seldom failures.
In order to rule out this possibility and stabilize the test, let's retry
on connection refused only. If we continue to fail, then the next step would
be to dump the content of iptables to figure out why the error occurs.
This patch doesn't changes behaviour of dhcp-agent
but adds the opportunity to use user-defined config,
that will make dhcp-agent more flexible
and allows to run functional tests correctly
(without changing global oslo.config CONF)
This patch deals with the lock wait timeout and the deadlock errors
observed under high concurrency (api_workers >= 4) with the pymysql
driver. It includes the following changes:
- Stop setting dirty status for resource usage when creating
reservation, as usage of reserved resources is not tracked anymore;
- Add a variable, increasing delay when retrying make_reservation
upon a DBDeadlock error in order to reduce the chances of further
collisions;
- Enable transaction retry upon DBDeadlock errors for set_quota_usage;
- Do not resync quota usage while making reservation. This puts a lot
of stress on the database and is also wasteful since resource usage
is very likely to change again once the transaction is committed;
- Use autonested_transaction to simplify logic around when the
nested flag should be used.
Moshe Levi [Tue, 18 Aug 2015 05:48:24 +0000 (08:48 +0300)]
Qos SR-IOV: Refactor extension delete to get mac and pci slot
When calling delete we need the pci slot details to reset the VF rate. The problem
is that when the VM is deleted libvirt return the VF to the hypervisor and eswitch
manager will mark the pci_slot as unassigned so can't know from the mac which pci slot (VF)
to reset. Also newer libvirt version reset the mac when deleteing VM, so than it is
not possible at all.
The solution is to keep pci slot details locally in the agent since upon removal event
you cannot get pci_slot from the neutron server as it is for create/update since port
is already removed from neutron.
This patch pairs the mac and pci_slot for a device (VF) so when calling the extension
port delete api we can have the pci_slot and reset the VF rate.
It is also add a mapping between mac to port_id so we can pass the port_id
when calling the extention port delete api.
OVS agent: handle deleted ports on each rpc_loop iteration
Currently rpc loop processes ports only in case polling is required
(message from ovsdb monitor) or there are port_updated notifications from
server or security group notifications.
In case of just port_deleted notifications port processing is not
triggered during rpc loop.
This may lead to agent accumulating a big amount of deleted ports
and processing all of them at once during next iteration when polling is
required or any notification from server, which might be quite tough for
the agent. Tough means agent will be irresponsive while processing deleted
ports.
The patch makes port deletion processing more gradual.
Shweta P [Thu, 27 Aug 2015 20:53:13 +0000 (16:53 -0400)]
Final decomposition of Cisco plugin
This patch follows the previous patch(listed as dependent) and moves
the remaining cisco db models from neutron to networking-cisco.
The patch deletes l3_model and cisco_router_plugin and their associated
config and helper files from neutron
Fixed functional test that validates graceful ovs agent restart
The async_ping function returns a callable that returns True when all ping
futures are done. Since those futures are running for 10 secs, there was no
chance that the result of the callable was True.
The test was bailing out without calling bridge reset even a single time,
effectively leaving the feature untested in gate.
Another thing to note is that for some reason the patch fixed oslo rootwrap
errors in the test when executed locally. Since I still don't understand how
it's possible that it fixes the issue for me, I mark the bug as related only,
and will track logstash after it's merged to see whether it applies unknown
magic to gate jobs too.
rossella [Wed, 26 Aug 2015 16:06:25 +0000 (16:06 +0000)]
_bind_devices query only existing ports
If a port is deleted right before _bind_devices is called,
get_ports_attributes will throw an exception since the row
corresponding to the port doesn't exist in the OVS DB.
Avoid that setting if_exists to True. The port will be
processed as deleted by the agent in the following iteration.
OVS agent: flush firewall rules for all deleted ports at once
In some cases, under high load OVS agent has to delete a big amount of
ports during rpc_loop. remove_devices_filter() does iptables-save/restore
for IPv4 and IPv6 which is 4 system calls. It is very expensive and
inefficient to call it for each port individually.
* Skip TestWSGIServerWithSSL[1] for Python 3 since it seems wsgi + ssl +
eventlet setup does not behave correctly now,
* Skip test_json_with_utf8[2] until we solve unicode/utf8 encode/decode,
* Fix some more tests to pass for py3,
* Replace print by print() in docs/docstrings.
Tu Hong Jun [Thu, 20 Aug 2015 06:08:07 +0000 (14:08 +0800)]
Changed filter field to router_id
The get_sync_interfaces query will always return all router ports
from database even it is supposed to query specific ones that
belong to a certain router. In large L3 scale environment with
number of route ports in place, this would lag the response time
for adding router interface and router L3 agent binding.
Sergey Vilgelm [Mon, 31 Aug 2015 14:06:48 +0000 (17:06 +0300)]
Fix a wrong condition for the _purge_metering_info function
Fix a situation for the _purge_metering_info function
when the items will never be deleted from the metering_info.
Delete the metering_info dict and use the metering_infos instead.
Fix the problem with changing a dictionary during iteration.
Add the unit tests for the _purge_metering_info and
_add_metering_info functions.
Make sure service providers can be loaded correctly
This patch fixes a regression where, if neutron was loaded using
--config-dir, the service_providers option was no longer available.
We bring the logic back (removed by 61121c5f2af), alongside the ability
to load the option auto-magically. This is especially required for DevStack
deployments as of today, because neutron-server is only loaded by passing
--config-file (...)neutron.conf and --config-file (...)ml2_conf.ini
Terry Wilson [Tue, 16 Jun 2015 03:52:28 +0000 (22:52 -0500)]
Add support for PluginWorker and Process creation notification
There are several cases where plugin initialization should be
handled after neutron-server forks API/RPC workers. For example,
starting a client connection to an SDN controller before forking
copies the fd of the socket to the child process, but then you have
multiple processes trying to read/write the same socket connection.
It is also useful for a plugin to be able to do something in only
one process, regardless of how many workers are forked. One example
would be handling syncing from an external system to the neutron
database.
This patch does 3 things:
1) Treats rpc_workers=0 as = 1. This simplifies the code for
handling notification that forking has completed. In the
existing code, calling the notification in the Worker object's
start() method would happen twice in the case where both api
and rpc workers were 0, despite there being only one process.
An earlier patch already changed the default api_workers to be
the number of processors.
2) Adds notification of forking via the callbacks mechanism.
Plugins can subscribe to resources.PROCESS, event.AFTER_CREATE
and do any post-fork initialization that needs to be done for
every spawned process.
3) Adds core/service plugin calls to get_workers() which defaults
to returning (). Plugins that need additional processes to spawn
should just return an iterable of NeutronWorkers that will be
spawned in their own process.
Nick [Sun, 19 Jul 2015 14:41:27 +0000 (22:41 +0800)]
Implement external physical bridge mapping in linuxbridge
In some deployment scenario, it is not allowed to remove system
ethernet configuration from physical interface to newly-created
physical bridge by neutron due to some IT regulations.
End-users require to take advantage of the pre-existed(user-defined)
physical bridge to connect tap devices for neutron.
Oleg Bondarev [Wed, 12 Aug 2015 17:02:01 +0000 (20:02 +0300)]
Avoid DB errors when deleting network's ports and subnets
DB errors may occur when accessing query results
after the transaction was closed (like ObjectDeletedError).
Hence it's better to avoid DB object access especially
when it's not needed.
This patch changes _delete_ports() and _delete_subnets() to accept
only ids. Indeed, there is no need to pass db objects to these methods.
Kevin Benton [Fri, 28 Aug 2015 05:12:48 +0000 (22:12 -0700)]
Better message on allowed address pairs error
Neutron was throwing a 500 error when a non-iterable was passed
into allowed address pairs. This patch just catches that and
converts it into a regular badrequest message.
Closes-Bug: #1477829
Change-Id: I3c6f55df4912c7a9480fa097988f910b254572fd Signed-off-by: Kevin Benton <blak111@gmail.com>
Assaf Muller [Sat, 29 Aug 2015 15:32:19 +0000 (11:32 -0400)]
Add info to debug test_keepalived_respawns gate failure
Current theory is that there's a bug in external_process.active,
it returns True when it shouldn't, then kill -15 on the process
pid fails because the process isn't up. Added ps -p output to
see if the process is up or not.
James Arendt [Fri, 28 Aug 2015 23:33:44 +0000 (16:33 -0700)]
Make Neutron service flavor save service_type
While the service_type exists in the resource attributes and as
a database field for a Flavor, the creation dictionary did not
pass the value so the service_type was not being persisted
in the database nor returned.
Enhanced unit test to show problem. Test fails on old code
to save or return the input service_type.
James Arendt [Wed, 26 Aug 2015 23:53:24 +0000 (16:53 -0700)]
Add tenant_id to flavor service profiles attributes
Neutron v2 base.py auto populates a 'tenant_id' attribute on
calls if the attribute is not passed. This causes a POST
to create a flavor service binding to fail when verifying
attributes with:
Unrecognized attribute(s) 'tenant_id'
Solution is to add tenant_id as expected attribute in the
attribute map as done in other sub resources like QOS.
Remove implicit registration of *-aas service providers
Implicit registration can be dropped when explicit registration
for load balancer and vpn is implemented. Firewall does not
use service providers and the ServiceTypeManager, so the
precautionary step can be dropped altogether.
Support for configuring providers via the service_providers section
in neutron.conf, is no longer available, hence clear the stale
entry points.
Catch errors on 'port not found' while deleting subnet
In some circumstances (like the one triggered by the test_dhcp_ipv6 testcase)
calls to deleting a port and calls to deleting subnets can happen in straight
sequence.
If this happens the execution of the operations can interleave leading
to the subnet deletion to fail because the port has already gone. This patch
ensures a missing port is handled correctly.
The method delete_subnet is ginormous and hence impossible to test at a unit
level without proper refactoring. That can happen with a follow-up patch.
OVS-agent: Introduce Ryu based OpenFlow implementation
Introduce an alternative OpenFlow implementation, "native",
implemented using Ryu ofproto python library from Ryu SDN Framework.
Make it selectable with of_driver=native agent option.
The aim is to replace the existing ovs-ofctl based implementation
eventually.
It introduces node-local OpenFlow controller embedded in
OVS agent. Benefits include:
* Reduce the overhead of invoking ovs-ofctl command (and associated
rootwrap)
* Make future uses of OpenFlow asynchronous messages (e.g. Packet-In,
Port-Status, etc) easier
* Make XenAPI integration simpler
Highlights:
* Switch to OpenFlow 1.3.
* Make OVS-agent act as an OpenFlow controller
* Configure OVS on the node to connect to the controller
Kevin Benton [Wed, 2 Sep 2015 02:35:33 +0000 (19:35 -0700)]
Deprecate external_network_bridge option in L3 agent
This option provides another way to attach to a specific bridge
that is not quite equivalent with how bridge_mappings work in the
L2 agent. This creates inconsistencies between how the L3 agent
behaves when configured with a bridge_mapping and provider properties
of the Neutron network vs. when it just ignores all L2 stuff and
plugs itself directly into the bridge.
salvatore [Fri, 21 Aug 2015 08:44:25 +0000 (10:44 +0200)]
Do not track active reservations
Reservations have a transient nature: a reservation lifespan
typically begins and ends with a single request.
Therefore tracking reserved amounts for each tenant and resource
is not nearly as efficient as tracking resource usage.
Indeed it is fairly easy to verify that the overhead for tracking
reserved amounts is much greater than the one needed for counting
active reservations for each tenant and resource.
This patch removes the logic for tracking reservations, and
replaces it with an explicit count of active reservations.
Please note that this patch does not adjust accordingly the
ResourceUsage DB model. This will be done in a separate patch with
an expand migration; this should avoid most merge conflicts before
the final patch for restoring reservation logic merges.
Henry Gessau [Tue, 1 Sep 2015 21:17:01 +0000 (17:17 -0400)]
Deprecate --service option for neutron-db-manage
Now that https://review.openstack.org/198542 has merged we can
deprecate the --service option. From now on instead of
--service fwaas
we should instead use
--subproject neutron-fwaas
This puts the *aas subprojects on equal footing with the other
projects in the Neutron Stadium for neutron-db-manage.
In the Liberty release the --service option will be marked as
deprecated. It will be removed in Mitaka.
Sachi King [Tue, 1 Sep 2015 05:10:54 +0000 (15:10 +1000)]
Add constraint target to tox.ini
This adds a pip install command to tox.ini that is only used when the
tox env is passed with the 'constraints' factor appended onto it.
As such this will not effect developer workflows or current unit tests.
The initial use of this will be in a non-voting job, to verify that the
constrained checks with tox are stable. DevStack is already running
constrained jobs, as such problems are no expected.
To run a tox with pip using constraints on a developer system a
developer should run the desired tox environment with -constraints.
For example: $(tox -epy27-constraints)
Pip will pull the current version of the upper-constraints.txt file down
from the git.openstack.org, however this method can be overriden to use
a local file setting the environment variable "UPPER_CONSTRAINTS_FILE"
to the local path or a different URL, it is passed directly to pip.
This is currently not enabled in the default tox run, however it is
possible to enable it as a default by adding it to 'envlist' in tox.ini
Neil Jerram [Mon, 27 Jul 2015 13:41:29 +0000 (14:41 +0100)]
DHCP agent: allow using gateway IPs instead of uniquely allocated
In each place where the DHCP agent runs, and for each subnet for which
DHCP is handing out IP addresses, the DHCP port needs - at the Linux
level - to have an IP address within that subnet. Generally this
needs to be a unique Neutron-allocated IP address, because the
subnet's underlying L2 domain is bridged across multiple compute hosts
and network nodes, and for HA there may be multiple DHCP agents
running on that same bridged L2 domain.
However, if the DHCP ports - on multiple compute/network nodes but for
the same network - are _not_ bridged to each other, they do not need
each to have a unique IP address. Instead they can all share the same
address from the relevant subnet. This works, without creating any
ambiguity, because those ports are not all present on the same L2
domain, and because no data within the network is ever sent to that
address. (DHCP requests are broadcast, and it is the network's job to
ensure that such a broadcast will reach at least one of the available
DHCP servers. DHCP responses will be sent _from_ the DHCP port
address.)
Specifically, for some networking backends it makes sense to allow all
DHCP ports to use the subnet's gateway IP address, and thereby to
completely avoid any unique IP address allocation.
This change therefore enhances the DHCP agent code to be able to use
gateway IPs as an alternative to uniquely allocated ones, with the
choice between those being made by a new interface driver property,
'use_gateway_ips'. The back-compatible default is to use unique IPs.
An interface driver that wants the DHCP agent to use gateway IPs can
achieve that by overriding as follows:
Code Review / openstack-build / neutron-build.git / log