The functionality within neutron.db.common_db_mixin is available via
neutron-lib APIs. This patch removes common_db_mixin and updates any
uses of it to use neutron-lib instead.
Depends-On: https://review.openstack.org/#/c/636159/
NeutronLibImpact
Change-Id: I2388f90b37abb09408809dda8c21da551bcd94bb
Reduces E128 warnings by ~260 to just ~900,
no way we're getting rid of all of them at once (or ever).
Files under neutron/tests still have a ton of E128 warnings.
Change-Id: I9137150ccf129bf443e33428267cd4bc9c323b54
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
The neutron.db.api.context_manager already references neutron-lib's
context manager; so consumers of it are already using neutron-lib. This
patch switches neutron's references to the context_manager over to
use neutron-lib's directly rather than that in neutron.db.api.
NeutronLibImpact
Change-Id: I97120faeec73690592ed21a5ec3c6202f61e1429
The APIs our consumers are using from neutron.db_utils were rehomed into
neutron-lib with https://review.openstack.org/#/c/540161/
This patch consumes them by removing the rehomed APIs and using lib's
implementation where applicable.
NeutronLibImpact
Change-Id: I7ee53bce917feae8e37bf278eb3121a5af47131c
The flavors extension's API definition was rehomed into neutron-lib with
commit I0229a80bb168bac8dc0fa17fb2b06f1b140d27b4
This patch consumes it by:
- Removing the rehomed code and using neutron-lib's implementation
instead.
- Using the APIExtensionDescriptor for the extensions parent class.
NeutronLibImpact
Change-Id: I265ac1c0596d0fb0acaf99eeb7cfe9501732476f
Those were moved under neutron.db.models start of Ocata. We should be
able to clean them up now.
NeutronLibImpact
Change-Id: Iadbf44d52ee8e30712807384152a29ce1a8b8f72
Change I583aef9735cfa5984312507f66198d009eef9ce2 moved
_make_flavor_dict inside of the transaction to avoid detached
instance errors on loading the relationship. However, we should
avoid the pattern where we can of building the response before
the changes are flushed to the database because things like
default values on columns will not be evaluated yet.
This moves it back out of the transaction and adds a subquery lazy
load to the relationship required by the dict extend function to
avoid the detached instance error.
Partially-Implements blueprint: enginefacade-switch
Change-Id: I5d01ca79ee2970849c3f807232f658fa19a23592
This patch introduces and integrates Flavor and Service Profile model
classes to Oslo-Versioned Objects
Change-Id: I2963fabfc857ca68e9e6fb4e89e3c3ca6807a959
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
Co-author-by: Eli Qiao <liyong.qiao@intel.com>
Usage reader and writer for db operations with flavor.
The main problem is that we need to reload relationships(_make_dict
functions) after object is detached from current session, so
_make_dict* were moved under transaction to avoid using the DB
object outside of the transaction.
Partially-Implements blueprint: enginefacade-switch
Change-Id: I583aef9735cfa5984312507f66198d009eef9ce2
Extract all the common utils from common_db_mixin.py in preparation
for moving them to neutron-lib.
This is a preliminary step in preparation for refactoring the
CommonDbMixin class and moving it to neutron-lib also.
Partial Blueprint: neutron-lib
Change-Id: I3cba375a8162cb68e8f988f22f5c8b1ce7915180
This patch will separate flavor and service profile db models from
mixins for Oslo-Versioned Objects implementation work.
Change-Id: Ia35d24c075dc716e44fbf8a9b6a2ebb0297e7aa9
Partial-Bug: #1597913
The flavor framework currently has a TODO where the logic
to ensure the flavor isn't in use should be. Implementing
this logic will be a bit complicated this late in the cycle
since many different services can depend on the flavor.
For now we can at least catch the DBReferenceError when trying
to delete the flavor and convert it into the FlavorInUse
exception.
This leaves some notes inline about how we might go about
implemented the _ensure_flavor_not_inuse function.
Change-Id: I6bfe61645c6cee002020a507e489c3535d5026ab
Closes-Bug: #1621281
I saw a patch set [1] that was running in to circular imports and
removing these. I thought it'd be better to remove them all in one
shot.
[1] https://review.openstack.org/#/c/261222/1/neutron/db/agents_db.py
Change-Id: If1a9ba3091ac99f01f73b98a7459358c3efd4dd5
Make flavor service profile store actual driver instead of
hardcoded dummy driver. Ensure service type on flavor persisted.
Raise ServiceProfileDriverNotFound if non-empty driver is not part
of ServiceTypeManager providers.
Raise ServiceProfileEmpty if profile has neither a driver nor
any metainfo.
Raise InvalidFlavorServiceType if invalid service type passed.
Show flavors associated with a profile, not just profiles associated
with a flavor, to ease diagnosis when ServiceProfileInUse raised.
Create method to extract provider given a flavor for use with
neutron-lbaas plus tests.
Ensure various boolean forms accepted for enabled flag.
To enable in DevStack, add to local.conf:
enable_plugin neutron https://git.openstack.org/openstack/neutron
enable_service q-flavors
Add associated unit tests. Fix tempest api test that used invalid
LOADBALANCERS service type.
Change-Id: I5c22ab655a8e2a2e586c10eae9de9b72db49755f
Implements: blueprint neutron-flavor-framework
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.
Change-Id: I4dba287f5972ecebd193d65e7f542dd0a65f055b
Closes-Bug: 1490063
This patch introduces API and DB plugin for flavor framework.
API adds Flavors and Service Profiles which are resources
available only for admins to operate.
This framework then should be leveraged by advanced services.
Included tempest API tests in neutron tree
Implements: blueprint neutron-flavor-framework
Change-Id: I99ba0ce520ae3d8696eca5c994777c7d5ba3d4b1
Co-Authored-By: Doug Wiegley <dougw@a10networks.com>
Co-Authored-By: Madhusudhan Kandadai <madhusudhan.kandadai@hp.com>