With python 3.x, classes can use the metaclass= logic
to not require usage of the six library.
One step in removing all of six usage from neutron.
Change-Id: I2f815e412d9a96eb5faf2b3bb3a1e393a9db9309
Some service plugins make the assumption that Neutron is running
with a datastore (e.g. revision and timestamps). As the datastore
setup is a responsibility of the Neutron core plugin, checking
that this is indeed true avoids errors for those plugins that do
not implement any DB backend (e.g. monolithic OpenContrail plugin).
Change-Id: I872fa6e3c3925e521150d79bba864101d9a5f648
Closes-bug: #1700651
neutron-lib contains the WorkerBase class [1] that is the equivalent of
neutron's WorkerSupportServiceMixin. This patch switches over to
neutron-lib's version.
Note: IIUC no consumers are using WorkerSupportServiceMixin so this
patch can land without waiting for them to sync-up. I've included
the lib impact tag just in case.
NeutronLibImpact
[1] https://review.openstack.org/#/c/424151/
[2] http://codesearch.openstack.org/?q=WorkerSupportServiceMixin
Change-Id: Iacf1b6dfe318e3e6cfc76e61c65d407cf9ae7b36
This reverts commit b1cdba1696
Original patch was reverted because it broke neutron plugin's
backward compatibility and needed more work.
This patch fixes that problems:
1) original behaviour of add_agent_status_check,
start_periodic_l3_agent_status_check and
start_periodic_dhcp_agent_status_check methods is deprecated but kept
for using in third part plugins for backward compatibility
2) new add_agent_status_check_worker, add_periodic_l3_agent_status_check
and add_periodic_dhcp_agent_status_check method are implemented
instead and are used for implementing plugins in neutron codebase
Closes-Bug: #1569404
Change-Id: I3a32a95489831f0d862930384309eefdc881d8f6
I think this needs a little more thought. This broke OVN at least and
I don't think that's good. We need to figure out how to be compatible
with existing plugins, even out of tree ones.
This reverts commit 1cafff0871.
Change-Id: Ie087fb11213cc85911483c2d32c463fa9c973e54
Forking a process when multiple threads are running is an unsafe
operation and could cause a lot of problems because only current
thread will continue working in child thread. Any locked by other
thread resource will remain locked forever.
We faced with this problem during oslo.messaging development and
added workaround to hide this problem:
https://review.openstack.org/#/c/274255/
I tried to fix this problem in oslo.service:
https://review.openstack.org/#/c/270832/
but oslo folks said that this fix is ugly and it is wrong way to add
workarounds to common libraries because projects use them incorrectly.
I think that is fair.
So this patch fixes incorrect usage of oslo libraries. In this patch
I extended functionality of NeutronWorker and add there
`worker_process_count` parameter which determines how many processes
should be spawned for this worker. If `worker_process_count` = 0 - don't
create process and spawn thread in scope of current process for worker
Then I moved all background tasks to workers and return them by
`get_workers` method. start_plugin_workers collects plugin's workers
using `get_workers` method and starts in ProcessLauncher first workers
with `worker_process_count` > 0 and only after this starts threaded
workers by simple Launcher
Closes-bug: #1569404
Change-Id: I0544f1d47ae53d572adda872847a56fa0b202d2e
By default spawn one additional rpc worker to process
state report queue.
State report queue will also be processed by regular
rpc workers, but in case these workers are busy with
processing heavy requests, state reports queue will
automatically be consumed by dedicated rpc workers.
This change applies to ML2 plugin only.
Other plugins should implement start_rpc_state_reports_listener
to enable additional rpc workers.
Change-Id: I5f8df6a478f7c82382049274b34b07109eeafbdb
Closes-Bug: #1505217
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.
DocImpact
Closes-Bug: #1463129
Change-Id: Ib99954678c2b4f32f486b537979d446aafbea07b
Enable creating, reading, updating, and deleting subnet pools via REST API.
Includes required changes to REST, model, alembic migrations, and unit tests.
Subnet pools carry a list of IPv4 or IPv6 prefixes from which a subnet can be
allocated. This will enable tenants to request a subnet from a pool rather
than being forced to explicitly provide their own CIDR's for their subnets.
This change simply enables managing the lifecycle of a subnet pool and does
not yet enable allocation of subnet prefixes from a pool.
Subnet pools can have their prefix bounds (min, max, default), name, and
prefix list updated. Changes to prefix bounds do not alter existing
allocations and will not be blocked by existing allocations. Prefix lists can
only be appended to. Prefixes cannot be removed from the pool once added.
ApiImpact
Partially-Implements: blueprint subnet-allocation
Change-Id: I88c6b15aab258069758f1a9423d6616ceb4a33c4
Now that we explicitly start multiple RPC servers, renamed the method to
reflect behaviour.
blueprint oslo-messaging
Change-Id: I7c51cc1b44b4b4c8899255b9bedce1792c38634e
Metaplugin needs a fix to support multiple RPC workers properly
because a plugin which supports multiple RPC workers cannot
initialize RPC connections at plugin initialization.
Closes-Bug: #1300570
Change-Id: I584f70abb8969054cd4edc8f914d00f6be930bab
This commit enables the H301 hacking rule by removing all the
multiple imports in a single line from neutron.
Partial-Bug: #1291032
Change-Id: I7ba7f82fb36a433d73190eb3d568b6961ccb57c6
In the process __init__.py involved have been emptied;
vim modelines and author lines have been dropped from
the license headers affected by the change as well.
Partial-implements blueprint nicira-plugin-renaming
Change-Id: I9c535b59bb2e83f275816472e0e32b41444d3bbe
__metaclass__ cannot be used in python3.
six be used in general for python 3 compatibility.
Change-Id: Ib0d71b9676dc01390679396443575c05975d3b58
Closes-Bug: #1236648
This change renames everything to Neutron while providing backwards
compatible adjustments for Grizzly configuration files.
implements blueprint: remove-use-of-quantum
Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
Brian Haley