Removed E125 (continuation line does not distinguish itself
from next logical line) from the ignore list and fixed all
the indentation issues. Didn't think it was going to be
close to 100 files when I started.
Change-Id: I0a6f5efec4b7d8d3632dd9dbb43e0ab58af9dff3
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 port security API definition has been in neutron-lib for awhile.
This patch consumes the definition from neutron-lib.
NeutronLibImpact
- Consumers using the public definitions from
neutron.extensions.portsecurity must now switch over to the api-def in
neutron-lib. See the changes herein for additional details.
Change-Id: If43b65861efc536d01c43dc0d2bbcbcf062c1271
By registering functions directly we cut off the dependency of the
"resource extend" functions on the plugin. This is a step towards
the goal of removing the CommonDbMixin mixin class.
Also, we register all "resource extend" functions at plugin create
(in __new__) instead of in the class definition (which caused the
hooks to be registered on import). This ensures the "resource
extend" functions are only registered for the plugins/mixins that
are actually used.
Note that decorators are used to register "resource extend" methods,
similar to the callback receiver decorators.
Related-Blueprint: neutron-lib
Change-Id: I128cfda773d5f9597df9cd61261fdc05f2a174aa
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
Those objects are intentionally not integrated into the database code so
far. This is to quicken access to their definitions to implement
push-notifications for networks.
Segments are part of the network object. Since we need to reduce the
number of SQL queries executed per resource, and we want to include
segmentation information for networks, Network model was extended with
segments relationship that makes the information available on every
network resource fetch from the database. This change required some
change in test_dhcp_agent_scheduler to expire a session used in the
tests to avoid obsolete segment state to be reused to validate
scheduling.
This implementation of the object is not complete for the job of
updating the resource in database. For example, tags are not yet exposed
on the object; also attributes like availability_zones, or external
network attributes, are not covered. Those attributes are hopefully
needed on server side only, so until we adopt the object for server
side, it should be ok to live without them.
Another database related thing still missing in this patch is lack of
RBAC support for the object. To complete this support,
a real get_bound_tenant_ids should be put onto the object, instead of
the current no-op stub.
This patch also includes some rearrangements that simplified the work.
Specifically, all network related objects are consolidated in the
neutron.objects.network module, instead of being scattered through the
code base. Also, some setup code from test_policy relevant to RBAC was
moved into the base test class so that it can be utilized by other RBAC
enabled objects, like network.
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
Partially-Implements: blueprint push-notifications
Co-Authored-By: Victor Morales <victor.morales@intel.com>
Change-Id: I5160d0ab9e8042c356229420739db0ce42842368
Since there are two models for binding, and it's easier if they behave
identically from objects POV, renamed port_id field in PortSecurity into
id, and kept the same fields in NetworkPortSecurity.
Switched db code to using those objects. Some refactoring took place to
reduce code duplication.
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
Change-Id: Ic104f113c4aa3f0c1448f83fe5128feed7b4444b
Resources could be created before the extension was enabled in the
setup. In that case, no bindings are created for them. In that case, we
should gracefully return default (True) value when extracting the value
using the mixin; and we should also create binding model on update
request, if there is no existing binding model for the resource.
While at it, introduced a constant to store the default value for port
security (True) and changed several tests to use the constant instead of
extracting it from extension resource map.
Change-Id: I8607cdecdc16c5f94635c94e2f02700c732806eb
Closes-Bug: #1509312
While db columns and api attribute happen to have same name here,
it's still better to distinguish them.
Change-Id: I6d6e649925a41d89fd74ca5e64290737c9baed9a
Add portsecurity extension driver into ML2 plugin and implement it in
iptables_firewall.
The scope of this change is:
- Abstract a common class PortSecurityDbCommon from the old
PortSecurityDbMixin
- Add a new extension driver port-security, implement process_xxx and
extend_xxx_dict method and provide a db migration from the existing
networks and ports
- Update the new added 'unfiltered_ports' in iptables firewall of l2 agent
to reflect the update of port-security
Co-Authored-By: Shweta P <shpadubi@cisco.com>
Change-Id: I2da53168e2529db7a8094ce90ef3a8a93fe55727
Partially Implements: blueprint ml2-ovs-portsecurity
Brian Haley