Red Hat Bugzilla – Bug 1262425
memcached needs the interleave=true pacemaker attribute
Last modified: 2015-12-21 11:49:01 EST
Description of problem: osp-d creates the memcached resource as follows (CIB dump as pcs status does not show meta attributes in pcs status): <clone id="memcached-clone"> <primitive class="systemd" id="memcached" type="memcached"> <instance_attributes id="memcached-instance_attributes"/> <operations> <op id="memcached-start-timeout-60s" interval="0s" name="start" timeout="60s"/> <op id="memcached-monitor-interval-60s" interval="60s" name="monitor"/> </operations> </primitive> <meta_attributes id="memcached-clone-meta"/> </clone> Whereas the osp-ha reference architecture sets interleave=true <clone id="memcached-clone"> <primitive class="systemd" id="memcached" type="memcached"> <instance_attributes id="memcached-instance_attributes"/> <operations> <op id="memcached-monitor-interval-60s" interval="60s" name="monitor"/> </operations> </primitive> <meta_attributes id="memcached-clone-meta"> <nvpair id="memcached-interleave" name="interleave" value="true"/> </meta_attributes> </clone>
What is the overall impact of this bug, is it just an info display issue or does it cause other issues?
Mainly speed of starting all the services on a controller. Without interleave=true the cascade of services depending on memcached (keystone and services depending on keystone) will all need to wait for memcached to be started on *all* nodes before starting themselves. E.g. with memcached interleave=true, keystone on node A can start as soon as memcached on node A is started and does not need to wait for memcached to be started on node B and C. Fabio, anything I missed above?
(In reply to Michele Baldessari from comment #4) > Mainly speed of starting all the services on a controller. Without > interleave=true > the cascade of services depending on memcached (keystone and services > depending on keystone) will all need to wait for memcached to be started on > *all* nodes before starting themselves. > > E.g. with memcached interleave=true, keystone on node A can start as soon as > memcached on node A is started and does not need to wait for memcached to be > started on node B and C. > > Fabio, anything I missed above? That is correct, use of interleave=true decreases recovery time of services in case of some faults. It is already used for many openstack services, but for some reasons OSPd based deployments didn´t have it.
I need to partially backpedal on my comment #4. The issue here is *not* simply a speed of starting problem (which still holds true). The real problem is that whenever a controller joins a cluster (say after a reboot), pacemaker will consider memcached as a single unit on all nodes so it will restart keystone on every node. So this one is more important than initially thought. Putting Andrew in CC: as he provided this feedback in today's call
verified on RHEL-OSP director 7.2 puddle - 2015-11-25.2 using cibadmin --query --local: <clone id="memcached-clone"> <primitive class="systemd" id="memcached" type="memcached"> <instance_attributes id="memcached-instance_attributes"/> <operations> <op id="memcached-start-interval-0s" interval="0s" name="start" timeout="100s"/> <op id="memcached-stop-interval-0s" interval="0s" name="stop" timeout="100s"/> <op id="memcached-monitor-interval-60s" interval="60s" name="monitor"/> </operations> </primitive> <meta_attributes id="memcached-clone-meta_attributes"> <nvpair id="memcached-interleave" name="interleave" value="true"/> Info: rpm: openstack-tripleo-heat-templates-0.8.6-85.el7ost.noarch HA-environmet: 3 controllers, 3 computes
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2650