Hi Sergey! Comments inline.

On 11/20/2014 05:25 AM, Sergey Vasilenko wrote:
    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:

Completely agree with you here for the Neutron agents, since they are not the same as the other OpenStack controller services. The Neutron agents keep state, and therefore are appropriate for management by Pacemaker, IMO.

  * *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
  * 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.

For endpoints that need more than an HTTP check, absolutely, you are correct. But, in real life, I haven't really seen much need for more than an HTTP check for the controller services *except for the Neutron agents*.

All the best,

OpenStack-dev mailing list

Reply via email to