Open Stack

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141120/f03c40e7/attachment.html>