I am not 100% sure what that is but it seems like an experiment that
never gave fruits. Since the introduction of the code, we had huge
changes in how we test api, we got tempest plugins, we steadily move
from api testing in unit tests, we have fullstack, etc.
I assume if I can't understand what's use of that, then it's probably
irrelevant code, and so it's better to clean it from the tree.
Change-Id: I0b1be0c761da75885981952a4f5ab5a43bc09525
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
The oslo.db opportunistic test fixtures were not being
used effectively and the MySQL / PG databases were not
being used. This patch restores working patterns against
oslo.db. Additionally, the migration level tests have also
been updated to make use of oslo.db provisioning functionality
and unused methods have been removed.
The current approach makes use of oslo.db provisioning constructs
directly, as well as some semi-private attribute access within
oslo.db enginefacade, in order to work around some issues
that have arisen in oslo.db's test_base.
A new release of oslo.db will provide
public API points to resolve pending issues, and to
allow neutron's use cases here which will
also be of general applicability to openstack projects.
Closes-bug: #1594898
Change-Id: Ie27cf174fa24c2f479af47335d9ae139fb7d159a
The check of the tenant done in the method _get_tenant_id_for_create()
is already did by the Neutron Controller in prepare_request_body(),
with a call to attributes.populate_tenant_id().
Moreover, when the Controller processes a "create" requests, it
will add the 'tenant_id' to the resource dict.
Thus, _get_tenant_id_for_create() can be deleted.
Calls to this method are replaced by the res['tenant_id'].
Changes have to be done in UT to explicitly add the tenant_id while
creating resources, since the UT framework is bypassing the controller code
that automatically adds the tenant_id to the resource.
Co-Authored-By: Hong Hui Xiao <xiaohhui@cn.ibm.com>
Closes-Bug: #1513825
Change-Id: Icea06dc81344e1120bdf986a97a6b1094bbb765e
Depends-On: I31022e9230fc5404c6a94edabbb08d2b079c3a09
Depends-On: Iea3f014ef17a1e1b755cd2efe99afd1a36ebbc6a
Depends-On: I604602d023e0cbf7f6591149f914d73217d7a574
Went through all of the docstrings in Neutron and did
some cleanup. I'm sure there are bunch more that I have missed.
Change-Id: Ib29d2de1c580880c89ed4fd069e1515d0977a3e7
The rename from Quantum to Neutron left a few q_ strings
around, let's go ahead and clean them up.
Change-Id: I06e6bdbd0c2f3a25bb90b5fa291009b9ec2d471d
There were two broad issues with fixtures.
Firstly, the 'SafeFixture' workaround for resource leaks in fixtures
<1.3 is not needed if we depend on fixtures>=1.3.1. While testtools
may raise a TypeError when trying to query a fixture that failed to
setup, this is only ever a cascading failure - it will not cause
tests to fail, cause leaks, or cause tests to incorrectly pass. That
will be fixed in testtools soon to stop it happening (but as it cannot
affect whether a test passes or fails or leaks happen there is no
reason to wait for that). Leaks are seen with fixtures 1.3.0 still
because eventlet raises a BaseException subclass rather than an
Exception subclass, and fixtures 1.3.0 didn't handle that - 1.3.1 does.
Secondly, some of the fixtures had race conditions where things were
started and then cleanups scheduled. Where possible I've fixed those,
but some of them require more significant work to fully address.
Change-Id: I3290712f7274970defda19263f4955e3c78e5ed6
Depends-On: I8c01506894ec0a92b53bc0e4ad14767f2dd6a6b3
Closes-bug: #1453888
Currenty useFixture(myfixture)[1] ensures to call myfixture.cleanUp only
if myfixture.setUp succeed.
This change defines a workaround to ensure cleanUp call even if setUp
fails until testtools/fixtures support it: SafeFixture[2] which ensures
cleanUp call if setUp fails and replaces fixtures.Fixture use by
SafeFixture. This workaround will be removed when the bug will fixed in
testtools and fixtures[3].
[1] testtools.TestCase.useFixture, fixtures.Fixture.useFixture
[2] neutron.tests.tools
[3] see related bugs
Change-Id: I875934e8dde321a450c83fb95d175affd1f3bb83
Closes-Bug: #1464410
Partial-Bug: #1453888
Related-Bug: #1456353
Related-Bug: #1456370
* Moving VLAN Transparency support from core to extension
* Remove the older unit tests and add new corresponding ones
DocImpact
Closes-Bug: #1434667
Change-Id: Ic551475ed7b64aad9627a57abb0df41acc19bfc1
The retargetable testing prototype previously relied on each test case
defining the 'scenarios' attribute used to parametize testing with
testscenarios. Anticipating the requirement to retrofit the imported
tempest api test cases, this change moves scenario definition to a
base class since scenarios are common across all api tests.
This change also sets the retargetable test to skip when invoked
against rest. Tempest uses class-level setup for auth and this needs
to be broken out into fixtures before the retargetable testing will
work again.
Change-Id: I70eb21db9b983d45e9bcc7ea90e36f202d3e3e45
Ihar Hrachyshka