Open Stack

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.Venkatachalam at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/0b09e5cb/attachment.html>