<div dir="ltr">Hi Vijay,<div><br></div><div>Thanks for bringing this up. This is rather important API requirement to maintain actual member status.</div><div><br></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">> One could argue that a periodic task could be started by the plugin driver instead of the agent, to collect the member </span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">> statuses. But since this is a requirement from many drivers, it is better to be implemented as part of the LBaaS plugin.</span><br></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br></span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">I think that while that could certainly be a common code (no matter where), the stats gathering itself should be grained per-driver.</span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">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. s</span><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">uch stats gathering may become a point of contention. </span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">Also, each driver could use it's own way of communicating with backend devices which might complicate this task.</span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br>
</span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">Currently I'm still thinking about running this as a part of the driver in a separate thread (may be in several threads)</span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">In fact, it also makes sense to do it within the driver because we already have existing drivers which do it their own way.</span></div><div>
<span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br></span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">Let's discuss this on the next lbaas meeting.</span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br></span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">Thanks,</span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px">Eugene.</span></div>
<div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br></span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br></span></div><div><span style="font-family:Calibri,sans-serif;font-size:15px;text-indent:48px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 26, 2013 at 10:35 AM, Vijay Venkatachalam <span dir="ltr"><<a href="mailto:Vijay.Venkatachalam@citrix.com" target="_blank">Vijay.Venkatachalam@citrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi Eugene et al,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> 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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="text-indent:.5in">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. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> 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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> This approach is not suitable for agent less models.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="text-indent:.5in">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<br>
Vijay V.<u></u><u></u></p>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>