Open Stack

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

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,
-jay