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 <phillip.tooh...@rackspace.com> > 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 <vijay.venkatacha...@citrix.com > <mailto:vijay.venkatacha...@citrix.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> > Date: Wednesday, February 4, 2015 12:19 PM > To: "doug...@parkside.io <mailto:doug...@parkside.io>" <doug...@parkside.io > <mailto:doug...@parkside.io>>, "OpenStack Development Mailing List (not for > usage questions)" <openstack-dev@lists.openstack.org > <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 > <vijay.venkatacha...@citrix.com <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 >> <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
__________________________________________________________________________ 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
