<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack services that run on a "controller node" are completely stateless. Therefore, I don't see any reason to use corosync/pacemaker for management of these resources.</blockquote><div><br></div><div>I see following reasons for managing neutron agents by Pacemaker:</div><div><ul><li><b>co-location</b> between resources. For example, L3 and DHCP agents should be run only on nodes, that has properly work openvswitch (or another L2) agent. Then L2-agent works wrong -- L3 and DHCP agents should be stopped immediately. Because Neutron don't control this situation and can allocate some resources (router or subnet) to an agent.<br></li><li>extended <b>monitoring</b>.  Traditional OS init/upstart subsystem allow only simple status checking (may be exclude systemd). Now we have situation, for example with neutron agents, then some of agent pretends to well-working. But in really, do nothing. (unfortunately, openstack developed as is) Such agent should be immediately restarted. Our Neutron team now works on internal health-checking feature for agents, and I hope, that this will implemented in 6.1. For example we can make simple checking (pid found, process started) every 10sec, and more deep (RMQ connection, internal health-checking) -- mo rare.<br></li><li>No different business-logic for different OS. We can use one OCF script for Ubuntu, Centos, debian, etc...</li><li>handle cluster partitioning situation.</li></ul></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> haproxy should just spread the HTTP request load evenly across all API services and things should be fine, allowing haproxy's http healthcheck monitoring to handle the simple service status checks.<br></blockquote><div><br></div><div>Just HTTP checking not enough. In the future will be better make more deep checking personal for each openstack service. </div></div><br></div></div>