Change-Id: I52ec8a7b6d7b562e151bd213eb82f701290063ba
6.3 KiB
LBaaS Driver Interface changes for new Object Model
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/neutron/+spec/lbaas-objmodel-driver-changes
The upcoming LBaaS object model and API changes for Juno will require some driver interface changes, for new objects and backwards compatibility.
New interfaces include create_load_balancer (and the rest of crud) and create_listener. Create_vip is going away, and will be supported in a shim layer for older drivers. M:N health monitor associations are also going away.
The new object model and API blueprint: https://blueprints.launchpad.net/neutron/+spec/lbaas-api-and-objmodel-improvement
This blueprint does not cover changes for the new TLS or L7 functionality.
Problem description
With the upcoming LBaaS object model and API changes, we will need new interfaces for the backend load balancing drivers, and a shim layer so that things continue to work with older drivers during a depcrecation period.
Proposed change
When loading the driver, neutron will determine if it is a new object model driver or an older legacy driver, and pick an appropriate implemenation/shim class depending on which.
The new driver interface methods will be passed objects with attributes, instead of dictionaries as used in the icehouse drivers. For expediency's sake, initially these objects will be the standard neutron sqlalchemy objects, but full sqlalchemy functionality is not guaranteed in the future. Basic attributes and dependent object lookups will be supported long-term.
The new driver interface will be made up of handler classes that implement create, update, and delete methods. Example, subject to change:
sample_driver.py:
class SampleDriver(LoadBalancerAbstractDriver):
def __init__(self):
self.load_balancer = MyLoadBalancerManager(self)
self.listener = MyListener(self)
self.member = ef.MemberHandler(self)
self.stats = xyz.foo.StatsGatherer(self)
self.health_monitor = HMHandler(self)
class MyLoadBalancerManager(BaseManager):
def __init__(self, driver):
self.driver = driver
def create(self, context, lb_obj):
print("create")
def update(self, context, lb_obj):
print("update")
def delete(self, context, lb_obj):
print("delete")
Supported driver handlers: * load_balancer * listener * pool * member * health_monitor * stats
The following older driver methods will be translated/supported. Differences from existing behavior are noted next to each method.
- create_vip - combination of one load_balancer and listener object from above.
- update_vip
- delete_vip
- create_pool - first object created
- update_pool
- delete_pool
- stats
- create_member
- update_member
- delete_member
- update_pool_health_monitor
- create_pool_health_monitor
- delete_pool_health_monitor
Limitations of older driver shim:
- Multiple listeners on a load balancer is not supported.
- Multiple pools on a listener is not supported.
- Many-to-many associations for health monitors is not supported.
- Subnet id's on member objects are not supported.
Driver breakage:
- Some references to ldb.Vip will break until their maintainers update the relevant driver (embrane, radware). Tests for those drivers will be temporarily disabled until fixed.
Alternatives
One proposed alternative for the backwards compatibility shim layer for the drivers is to create a completely separate new LBaaS extension/plugin, with completely separate database tables, and let both exist. This would involve duplicate drivers and db tables. We decided not to use this approach, and the general implementation plan for the lbaas api/driver changes:
- Create new LBaaS extension using database tables that have merged fields between old and new model.
- Change front-end of old extension to "translate" into operations on new model.
- Changer drivers to use new model.
- Deprecate / delete unused old model fields from database.
- Deprecate / delete old front-end.
Data model impact
None, refer to object model blueprint.
REST API impact
None, refer to object model blueprint.
Security impact
None, same impact as current driver implementations.
Notifications impact
None.
Other end user impact
None.
Performance Impact
None, same impact as current driver implementations.
Other deployer impact
Upgrade to new LBaaS will involve a db migration; refer to object model blueprint. Older LBaaS drivers will continue to work, except that attempting to add multiple listeners to a load balancer will fail.
Developer impact
Current LBaaS driver maintainers will need to eventually update their drivers to the new interface.
Implementation
Assignee(s)
- Primary assignee:
-
https://launchpad.net/~brandon-logan https://launchpad.net/~dougwig
Work Items
- Modify layer above drivers to call new entry points.
- Modify layer above drivers to call old driver interface methods for older drivers, translating the newer object model as needed.
- New abstract_driver with new interfaces.
Updating the reference haproxy driver will be in another blueprint.
Dependencies
Testing
- Existing tests against older drivers will continue to pass, unless testing the M:N health monitor relationship.
- New tests will be added for new entry points will be added when the reference driver is updated.
- Broken drivers, as specified in "Proposed change", will result in disabled tests until the drivers are fixed.
Documentation Impact
None.