> > 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.
I see following reasons for managing neutron agents by Pacemaker: - *co-location* 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. - extended *monitoring*. 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. - No different business-logic for different OS. We can use one OCF script for Ubuntu, Centos, debian, etc... - handle cluster partitioning situation. > 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. > Just HTTP checking not enough. In the future will be better make more deep checking personal for each openstack service.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
