I’d recommend taking a look at Brandon’s review: https://review.openstack.org/#/c/144834/ <https://review.openstack.org/#/c/144834/>
which aims to simplify exactly what you’re describing. Please leave feedback there. Thanks, doug > On 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
