Open Stack

Hi Vijay,

Thanks for bringing this up. This is rather important API requirement to
maintain actual member status.

> One could argue that a periodic task could be started by the plugin
driver instead of the agent, to collect the member
> statuses. But since this is a requirement from many drivers, it is better
to be implemented as part of the LBaaS plugin.

I think that while that could certainly be a common code (no matter where),
the stats gathering itself should be grained per-driver.
In fact the more balancers are started, the less is a chance that statuses
of all members/pools are updated on time if they are gathered from one
thread walking over the devices. E.g. such stats gathering may become a
point of contention.
Also, each driver could use it's own way of communicating with backend
devices which might complicate this task.

Currently I'm still thinking about running this as a part of the driver in
a separate thread (may be in several threads)
In fact, it also makes sense to do it within the driver because we already
have existing drivers which do it their own way.

Let's discuss this on the next lbaas meeting.

Thanks,
Eugene.





On Thu, Dec 26, 2013 at 10:35 AM, Vijay Venkatachalam <
Vijay.Venkatachalam at citrix.com> wrote:

>  Hi Eugene et al,
>
>
>
>                 As of today, during a stats API query, a pool member’s
> status is gathered along with the pool stats and stored in the db.
>  Subsequent GETs to the members will have the correct member status. In
> this approach, only when a North Bound API call for stats  is performed the
> member’s status would get refreshed. This is not desirable and the status
> should be up-to-date any point of time.
>
>
>
> My suggestion: We can introduce a new API as part of the driver interface
> like get_poolmember_statuses(poolid). The LBaaS plugin will call this on a
> periodic basis to collect member statuses and stores it in the db.
>
>
>
>                 HAProxy has taken a back door route to keep the status
> up-to-date. Here the HAProxy agent starts a periodic task that collects all
> “pool stats” + "member status” and updates the collected data in the db
> through a plugin driver callback.
>
>
>
>                 This approach is not suitable for agent less models.
>
>
>
> One could argue that a periodic task could be started by the plugin driver
> instead of the agent, to collect the member statuses. But since this is a
> requirement from many drivers, it is better to be implemented as part of
> the LBaaS plugin.
>
>
>
> Thanks,
> Vijay V.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131230/f518e39e/attachment.html>