In Ocata, notification_drivers were deprecated in favor of
the new QoSDriver architecture.
This patch removes backwards compatible support for notification
drivers along with its testing.
Change-Id: I5f747635be3fd66b70326d9f94c85a6736286bd2
This will deprecate the notification_driver config setting,
and no config setting will be needed.
Also it lays down the foundation for a more decoupled interaction
with mechanism drivers.
Closes-Bug: #1657379
Related-Bug: #1627749
DocImpact
Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48
Objects must use project_id and not tenant_id. The object framework
ensures that tenant_id is added as an extra field for backward
compatibility.
This patch reverts the workaround implemented in change
I4ec9340094bc51cd8aa6e5112bf8114aa26c2982 and implements a proper fix
by explicitly updating the objects.
Co-Authored-By: Artur Korzeniewski <artur.korzeniewski@intel.com>
Co-Authored-By: Darek Smigiel <smigiel.dariusz@gmail.com>
Closes-Bug: #1630748
Change-Id: Iab90bcab41655b2e210aea0e7581eb00b94ce5e5
Neutron Manager is loaded at the very startup of the neutron
server process and with it plugins are loaded and stored for
lookup purposes as their references are widely used across the
entire neutron codebase.
Rather than holding these references directly in NeutronManager
this patch refactors the code so that these references are held
by a plugin directory.
This allows subprojects and other parts of the Neutron codebase
to use the directory in lieu of the manager. The result is a
leaner, cleaner, and more decoupled code.
Usage pattern [1,2] can be translated to [3,4] respectively.
[1] manager.NeutronManager.get_service_plugins()[FOO]
[2] manager.NeutronManager.get_plugin()
[3] directory.get_plugin(FOO)
[4] directory.get_plugin()
The more entangled part is in the neutron unit tests, where the
use of the manager can be simplified as mocking is typically
replaced by a call to the directory add_plugin() method. This is
safe as each test case gets its own copy of the plugin directory.
That said, unit tests that look more like API tests and that rely on
the entire plugin machinery, need some tweaking to avoid stumbling
into plugin loading failures.
Due to the massive use of the manager, deprecation warnings are
considered impractical as they cause logs to bloat out of proportion.
Follow-up patches that show how to adopt the directory in neutron
subprojects are tagged with topic:plugin-directory.
NeutronLibImpact
Partially-implements: blueprint neutron-lib
Change-Id: I7331e914234c5f0b7abe836604fdd7e4067551cf
Refactoring neutron services config opts to be in neutron/conf/services
so that all the configuration options for services reside in a
centralized location. This simplifies the process of looking up the
extension config opts and provides an easy way to import.
Change-Id: Iad255b020910ee54bc6cce25f4f786376dfe3705
Partial-Bug: #1563069
There are usage patterns which would benefit from having
the capability to send a list of resources in bulk instead
of using individual fanout messages.
From now on, the rpc callback subscriber receives a list of
resources (single or multiple), and the pushers must always
push a list.
Backwards compatibility for QoSPolicy consumers in mitaka
is provided by calling push with "resource" parameter for
single item lists during one release cycle. That will be
dropped when Ocata opens.
Partially-implements: blueprint vlan-aware-vms
Change-Id: I1117925360a29ecbd1902fa527b2f24f94ce81ec
The QOS tests would have tons of warnings that real UUID's need to
be used. This patch fixes that.
We will not see any more:
.../oslo_versionedobjects/fields.py:325: FutureWarning:
fake_rule_id is an invalid UUID. Using UUIDFields with
invalid UUIDs is no longer supported, and will be removed
in a future release. Please update your code to input valid
UUIDs or accept ValueErrors for invalid UUIDs.
See http://docs.openstack.org/developer/oslo.versionedobjects/api/fields.html#oslo_versionedobjects.fields.UUIDField
for further details "for further details" % value, FutureWarning)
TrivialFix
Change-Id: Iee36c7d1cd11b6a38ab67883f91dcb3bdb4d4344
The update policy works. We still need to track down the deletes which
don't work currently.
Change-Id: I48e04b42c07c34cf1daa17e7a29a6950453946ff
Partially-Implements: blueprint quantum-qos-api
Split rpc.callbacks interface into consumer and producer parts.
Better terms are chosen for two RPC APIs we have:
- pull when a component actively requests a new object state;
- push when a component updates anyone interested about an object
change.
Also, for callback registration, the following terms are used:
- subscribe when a component is registered in consumer registry;
- provide when a component is registered in provider registry.
Covered the registries with some unit tests.
Lots of existing tests utilize the registries now, and need to be
isolated from other tests that mess with the managers (that are
singletons), so introduced a common qos base test class to mock the
manager with per-test instance of it).
Co-Authored-By: Ihar Hrachyshka <ihrachys@redhat.com>
Partially-Implements: blueprint quantum-qos-api
Change-Id: I130cfbc8b78da6df4405b90ea1ab47899491ba41
Also renamed service_notification_drivers into notification_drivers
since it's clear where it belongs anyway (it's in neutron.conf meaning
it's a server side configuration value).
Change-Id: I64610e4b60112daec982a8cacded9b9b936c10bd
Partially-Implements: blueprint quantum-qos-api
The agent based RPC notification driver for message queue is the default.
Added support for multiple notification drivers.
DocImpact
Partially-Implements: blueprint quantum-qos-api
Change-Id: I4108c3d111067d8217bc4112c05e1bde0125e0ef
Miguel Angel Ajo