So IIUC tooz would be handling the liveness detection for the agents. That would be nice to get ride of that logic in Neutron and just register callbacks for rescheduling the dead. Where does it store that state, does it persist timestamps to the DB like Neutron does? If so, how would that scale better? If not, who does a given node ask to know if an agent is online or offline when making a scheduling decision? However, before (what I assume is) the large code change to implement tooz, I would like to quantify that the heartbeats are actually a bottleneck. When I was doing some profiling of them on the master branch a few months ago, processing a heartbeat took an order of magnitude less time (<50ms) than the 'sync routers' task of the l3 agent (~300ms). A few query optimizations might buy us a lot more headroom before we have to fall back to large refactors. Kevin Benton wrote: > > One of the most common is the heartbeat from each agent. However, I > don't think we can't eliminate them because they are used to determine > if the agents are still alive for scheduling purposes. Did you have > something else in mind to determine if an agent is alive? > Put each agent in a tooz[1] group; have each agent periodically heartbeat[2], have whoever needs to schedule read the active members of that group (or use [3] to get notified via a callback), profit... Pick from your favorite (supporting) driver at: http://docs.openstack.org/developer/tooz/compatibility.html [1] http://docs.openstack.org/developer/tooz/compatibility.html#grouping [2] https://github.com/openstack/tooz/blob/0.13.1/tooz/coordination.py#L315 [3] http://docs.openstack.org/developer/tooz/tutorial/group_ membership.html#watching-group-changes __________________________________________________________________________ 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/20150411/7cffea1e/attachment.html>