Ihar Hrachyshka [Mon, 9 Jun 2014 13:14:14 +0000 (15:14 +0200)]
Removed 'rpc' and 'notifier' incubator modules
Port to oslo.messaging is done, so remove now unused pieces from the
tree.
Also removed obsolete bin/quantum-rpc-zmq-receiver. It comes from old
days of oslo-rpc, it was reimplemented later as
openstack/common/rpc/zmq_receiver.py in oslo-incubator, and we've
removed the whole tree for old RPC layer anyway.
TripleO's multi-node testing shows that this patch caused a failure to receive
tunnel updates, leading to the first node up to have no agent ports, the second
to have one agent port, the third to have 2 agent ports, etc. Needless to say,
this doesn't work all that well :)
Ihar Hrachyshka [Mon, 9 Jun 2014 12:42:25 +0000 (14:42 +0200)]
Renamed argument for create_consumer[s]
Now that we don't have explicit dispatcher class to pass into RPC layer,
and we pass a list of endpoints instead, fix names for corresponding
arguments of the functions.
Ihar Hrachyshka [Mon, 2 Jun 2014 15:40:38 +0000 (17:40 +0200)]
Port to oslo.messaging
Now that all preparations are done, actually port the code to use
oslo.messaging. This patch does as little as possible. Follow up patches
that refactor and cleanup the code and configuration files, will be
merged later. The reason for this is to make the patch as slim as
possible, to make review process more smooth and concentrated.
Details:
* neutron/common/rpc.py:
- added init() and cleanup() to set global RPC layer state.
- added utility functions: get_server(), get_client(), get_notifier()
that wrap up oslo.messaging API a bit, enforcing eventlet executor
and setting serializer, among other things.
- removed PluginRpcDispatcher, instead introduced PluginRpcSerializer
to use as a default serializer for API callbacks.
* neutron/common/rpc_compat.py:
- emulated incubator RPC layer behaviour thru previously introduced
stub classes (RpcCallback, RpcProxy, ...) using new oslo.messaging
API.
- switched to using new oslo.messaging exception types.
* neutron/service.py:
- expect multiple RPC listeners that are of MessageHandlingServer
type, not GreenThread.
* neutron/common/config.py:
- initialize RPC layer in init()
* setup.cfg:
- added entry points for old notifier drivers to retain backward
compatibility.
* neutron/tests/...:
- introduced fake_notifier to replace impl_fake.
- faked out consume_in_thread() to avoid starting RPC listeners when
running unit tests.
- used 'fake' transport driver.
- made sure neutron.test.* exceptions are caught.
- initialize and clean up RPC layer for each test case.
* Ported all affected code from using neutron.openstack.common.notifier
API to oslo.messaging.Notifier.
* rpc.set_defaults() was renamed to rpc.set_transport_defaults()
Terry Wilson [Wed, 18 Jun 2014 03:32:56 +0000 (22:32 -0500)]
Pass 'top' to remove_rule so that rule matching succeeds
When deleting a vpn-site-connection, deleting the nat rule would
fail because it was created with top=True, but top defaults to
'false' in remove_rule and was not being passed. This caused the
rule matching to fail and the rule to not be deleted.
Elena Ezhova [Wed, 11 Jun 2014 13:25:40 +0000 (17:25 +0400)]
Check port value when creating firewall rule with icmp protocol
If a firewall rule was created with setting protocol as icmp
and using source/destination port no error was thrown, even though
source/destination port parameters are not used by icmp.
This patch adds a validation method that checks passed parameters
and throws an exception if they are incompatible.
Kevin Benton [Wed, 18 Jun 2014 07:17:02 +0000 (00:17 -0700)]
Big Switch ML2: sync detection in port-update
Adds logic to the update_port_postcommit method of the
Big Switch ML2 driver to detect when afailure to update
the port via REST was caused by the backend being out-of-sync
with neutron.
This was accomplished by checking for the NXNETWORK message
which indicates that a port request referenced a network that
does not exist on the backend. This only occurs when they are
out-of-sync so the driver will then trigger a full topology sync.
The same logic exists in the port creation method shared with
the Big Switch plugin. However, the Big Switch ML2 driver does
not send port requests to the controller unless the port binding
host ID is set, which doesn't occur until a port update after
binding in the ML2 scenario. Therefore, the logic has to be repeated
in the ML2 driver port update operation.
Ihar Hrachyshka [Tue, 3 Jun 2014 19:05:20 +0000 (21:05 +0200)]
Make sure we call BaseTestCase.setUp() first
Some test cases instantiate RPC clients in setUp() before calling to
super(). After we port to oslo.messaging, we'll initialize RPC layer in
BaseTestCase, so we should make sure we call there before proceeding
with clients in subclasses.
Ihar Hrachyshka [Tue, 3 Jun 2014 11:30:58 +0000 (13:30 +0200)]
Don't instantiate RPC clients on import
In oslo.messaging port, we'll need to make sure no RPC clients or
servers or notifiers are created before RPC layer is initialized using
n_rpc.init(). This means that there should be no global objects that
create those objects on __init__.
There should also be no such class attributes because in that case
import will itself instantiate the object, probably before RPC layer is
ready.
Ihar Hrachyshka [Tue, 3 Jun 2014 10:39:17 +0000 (12:39 +0200)]
Configure agents using neutron.common.config.init (formerly .parse)
After oslo.messaging port is done, we'll need to initialize RPC layer
from all RPC agents. We'll put initialization into init() function, so
the first step for migration is to make agents use it.
The function is renamed to be explicit about the fact that we don't just
parse configuration by calling it, but also do other common
initializations, like setting RPC layer.
Darragh O'Reilly [Mon, 16 Dec 2013 14:03:37 +0000 (14:03 +0000)]
linuxbridge-agent: process port updates in the main loop
This patch changes the way the linuxbridge agent processes port update
notifications. It does the same for the lb-agent as was done for the
ovs-agent in I219c6bdf63b0b5e945b655677f9e28fa591f03cd.
Now the RPC call just adds the updated tap device name to a set of
updated devices, and the actual processing is done in the main RPC loop.
This should solve the problems were port_update RPCs were competing
with the main loop/greenthread and with each other to do the same task
- like adding a tap or interface to a bridge - which lead to races and
was inefficient. Now repeated port_update notifications received within
a single main loop iteration will be coalesced and processed only once.
Jakub Libosvar [Tue, 17 Jun 2014 15:20:25 +0000 (17:20 +0200)]
Notify systemd when starting Neutron server
systemd is notified only when Neutron is started with multiple api
workers. This patch adds systemd.notify_once() call when starting
Neutron server with api_workers=0
Aaron Rosen [Mon, 16 Jun 2014 22:41:04 +0000 (15:41 -0700)]
NSX: revert queue extension name change
The following patch: d7aa2dfcb14b84e2ef3242fb0787200d852d6103 renamed the
nvp-qos extension to qos-queue which breaks the integration with nova as
nova checks for the nvp-qos extension to be loaded and now it's called
qos-queue. This patch adds back nvp-qos for trunk chasers and another
patch will migrate nova from nvp-qos to qos-queue.
Vishal Agarwal [Mon, 16 Jun 2014 16:01:15 +0000 (21:31 +0530)]
Fix pool statistics for LBaaS Haproxy driver
Total connections was mapped to none of the counters
of haproxy. Active connections was mapped to active request
counter(qcur)) of haproxy which in low load situations
always remains zero.
Patch maps connections API counters to haproxy session counters
and fixes unit test accordingly.
Tom Fifield [Mon, 16 Jun 2014 09:15:42 +0000 (17:15 +0800)]
Fix opt helpstring for dhcp_lease_duration
Recently (https://review.openstack.org/#/c/92453), the
functionality of dhcp_lease_duration was changed to support
infinite lease times.
However, this change failed to update the associated help text
with the option declaration. This patch simply updates the text
so that the new functionality can be understood by the user.
Ihar Hrachyshka [Mon, 16 Jun 2014 07:17:10 +0000 (09:17 +0200)]
Consistently use jsonutils instead of specific implementation
jsonutils have several benefits in comparison to pure json
implementation, like enabling C boosted encoders and decoders for
Python2.6 by using simplejson when available.