I’d recommend taking a look at Brandon’s review: https://review.openstack.org/#/c/144834/
which aims to simplify exactly what you’re describing. Please leave feedback there. Thanks, doug On Tue, Feb 3, 2015 at 7:13 AM, Vijay Venkatachalam < vijay.venkatacha...@citrix.com> wrote: > Hi: > > > > In OpenStack neutron lbaas implementation, when entities are > created/updated by the user, they might not be associated with the root > entity, which is loadbalancer. > > Since root entity has the driver information, the driver cannot be called > by lbaas plugin during these operations by user. > > Such entities are set in DEFFERED status until the entity is associated > with root entity. > > During this association operation (listener created with pool), the driver > api is called for the current operation (listener create); and the driver > is expected to perform the original operation (pool create) along with the > current operation (listener create). > > This leads to complex handling at the driver, I think it will be better > for the lbaas plugin to call the original operation (pool create) driver > API in addition to the current operation (listener create) API during the > association operation. > > > > That is the summary, please read on to understand the situation in detail. > > > > Let’s take the example of pool create in driver. > > > > a. A pool create operation will not translate to a pool create api > in the driver. There is a pool create in the driver API but that is never > called today. > > b. When a listener is created with loadbalancer and pool, the > driver’s listener create api is called and the driver is expected to create > both pool and listener. > > c. When a listener is first created without loadbalancer but with a > pool, the call does not reach driver. Later when the listener is updated > with loadbalancer id, the drivers listener update API is called and the > driver is expected to create both pool and listener. > > d. When a listener configured with pool and loadbalancer is updated with > new pool id, the driver’s listener update api is called. The driver is > expected to delete the original pool that was associated, create the new > pool and also update the listener > > > > As you can see this is leading to a quite a bit of handling in the driver > code. This makes driver code complex. > > > > How about handling this logic in lbaas plugin and it can call the > “natural” functions that were deferred. > > > > Whenever an entity is going from a DEFERRED to ACTIVE/CREATE status > (through whichever workflow) the plugin can call the CREATE pool function > of the driver. > > Whenever an entity is going from an ACTIVE/CREATED to DEFERRED status > (through whichever workflow) the plugin can call the DELETE pool function > of the driver. > > > > Thanks, > > Vijay V. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev