Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Doug Wiegley]

Also please note that the interface still allows for adding shared support.  
It’s not just in the first implementation.

Thanks,
doug


> On Feb 4, 2015, at 5:15 PM, Phillip Toohill  
> wrote:
> 
> Sharing/reusing pools is a planned future feature. We are currently trying to 
> work towards getting something released and having shared pools would extend 
> that timeline to not meet our expectations. 
> 
> From: Vijay Venkatachalam  <mailto:vijay.venkatacha...@citrix.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> mailto:openstack-dev@lists.openstack.org>>
> Date: Wednesday, February 4, 2015 12:19 PM
> To: "doug...@parkside.io <mailto:doug...@parkside.io>"  <mailto:doug...@parkside.io>>, "OpenStack Development Mailing List (not for 
> usage questions)"  <mailto:openstack-dev@lists.openstack.org>>
> Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
> driver when entities get associated/disassociated with root entity?
> 
>  
> Thanks Doug.
>  
> My apologies for the delayed reply.
>  
> The change is merged, so replying here.
>  
> It is a welcome change in one way, there is always a root entity now in 
> perspective while creating any entity.
> Listener is created with loadbalancer and pool is created with listener.
> The problem itself is eliminated because there is no DEFERRED stage.
>  
> But, this restricts pool in one listener. Basically reusing of a pools across 
> listeners and loadbalancers is not possible now.
>  
> The use case of creating both a HTTPS vip and HTTP vip for the same pool is 
> lost.
>  
> Basically, a user who will need that, should create 2 pools with the same 
> members and manage them. Is that right?
>  
> Thanks,
> Vijay V.
>  
>  
> From: Doug Wiegley [mailto:doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com>] 
> Sent: Tuesday, February 3, 2015 10:03 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
> driver when entities get associated/disassociated with root entity?
>  
> 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 Tue, Feb 3, 2015 at 7:13 AM, Vijay Venkatachalam 
> mailto: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
>>   
>> A

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Phillip Toohill]

Sharing/reusing pools is a planned future feature. We are currently trying to 
work towards getting something released and having shared pools would extend 
that timeline to not meet our expectations.

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 4, 2015 12:19 PM
To: "doug...@parkside.io<mailto:doug...@parkside.io>" 
mailto:doug...@parkside.io>>, "OpenStack Development 
Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?


Thanks Doug.

My apologies for the delayed reply.

The change is merged, so replying here.

It is a welcome change in one way, there is always a root entity now in 
perspective while creating any entity.
Listener is created with loadbalancer and pool is created with listener.
The problem itself is eliminated because there is no DEFERRED stage.

But, this restricts pool in one listener. Basically reusing of a pools across 
listeners and loadbalancers is not possible now.

The use case of creating both a HTTPS vip and HTTP vip for the same pool is 
lost.

Basically, a user who will need that, should create 2 pools with the same 
members and manage them. Is that right?

Thanks,
Vijay V.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Tuesday, February 3, 2015 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?

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 
mailto: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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Vijay Venkatachalam]

Thanks Doug.

My apologies for the delayed reply.

The change is merged, so replying here.

It is a welcome change in one way, there is always a root entity now in 
perspective while creating any entity.
Listener is created with loadbalancer and pool is created with listener.
The problem itself is eliminated because there is no DEFERRED stage.

But, this restricts pool in one listener. Basically reusing of a pools across 
listeners and loadbalancers is not possible now.

The use case of creating both a HTTPS vip and HTTP vip for the same pool is 
lost.

Basically, a user who will need that, should create 2 pools with the same 
members and manage them. Is that right?

Thanks,
Vijay V.


From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Tuesday, February 3, 2015 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?

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 
mailto: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://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

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Doug Wiegley]

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 Feb 3, 2015, at 7:13 AM, Vijay Venkatachalam 
>  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

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Doug Wiegley]

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

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Doug Wiegley]

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 Feb 3, 2015, at 7:13 AM, Vijay Venkatachalam 
>  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

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Jain, Vivek]

Hi Vijay,
My understanding was that each vendor will have different behavior for entity 
creation. LBaaS apis will mark each entity as PENDING_CREATE (?) initially and 
its up to specific vendor driver whether to mark entities as DEFERRED or 
actually CREATE them on LB. Vendor logic can decide the action based on whether 
hierarchy/criteria is met per their LB prerequisite.

Thanks,
Vivek

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 3, 2015 at 5:13 AM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver 
when entities get associated/disassociated with root entity?

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-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

[Vijay Venkatachalam]

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