Bug 1287817

the tl;dr on this is great catch, can confirm on my environment too, is down to a rebase nit afaics in puppet-tripleo. I am really confused about what the downstream for that is, openstack-puppet-modules, *I think*. The related *upstream* patch is at https://review.openstack.org/#/c/204249/. Info/context below:

I can definitely confirm the behaviour in my environment. My last update failed, so control2 completed, but control0 failed and control1 wasn't updated at all. Can see no manila in /etc/haproxy/haproxy.cfg on control1 (not updated) but see it in 2 and 0 as reported by mcornea above.

Now looking at the actual loadbalancer.pp in /usr/share/openstack-puppet/modules/tripleo/manifests/loadbalancer.pp the file is kinda weird on control2. I mean, compared to the upstream change which merged at https://review.openstack.org/#/c/204249/3/manifests/loadbalancer.pp the loadbalancer.pp on my updated controller2 only has a part of that looking like:

  if manila {
    haproxy::listen { 'manila':
      bind             => $manila_bind_opts,
      collect_exported => false,
    }
    haproxy::balancermember { 'manila':
      listening_service => 'manila',
      ports             => '8786',
      ipaddresses       => hiera('manila_api_node_ips', $controller_hosts_real),
      server_names      => $controller_hosts_names_real,
      options           => ['check', 'inter 2000', 'rise 2', 'fall 5'],
    }
  }

in its entirety (wrt manila in that file), i.e. in particular there is no way to set manila to be on or off (should be off by default from that upstream change) - so if it has landed downstream which looks like it must have then it's had a bit of a bumpy landing. (openstack-puppet-modules-2015.1.8-30.el7ost.noarch on my environment) 

SO, this looks to me like a rebase nit/unintentional. I tried to  Looking at downstream 'openstack-puppet-modules' (I assume this is the downstream for puppet-tripleo and loadbalancer.pp) I see the offending commit at "Change-Id: Ic8deb77533f561cea7ce7db1d20f6be5e2dc0d33" "Remove httpchk option from haproxy listeners" which is a really old one apparently 2015-07-02 12:31:18 but committed in October 2015-10-10 02:06:25. I can usually recreate the gerrit URI from that change id but in this case am failing so can't give you the exact downstream review. But it is there in the loadbalancer.pp for sure. 

thanks, marios

sorry, should have included, that the openstack-puppet-modules package was updated on the 'completed' controller, and which delivered the offending loadbalancer.pp...  the package versions I have are like:

yum info openstack-puppet-modules on control 1 (not updated)
openstack-puppet-modules-2015.1.8-21.el7ost.noarch

but control 2 has (updated fine)
openstack-puppet-modules-2015.1.8-30.el7ost.noarch

Emilien, moving this one to opm as it looks like it's caused by a bad rebase/patch

Thanks James, that is true the rebase did not work correctly, my team is taking care of the bug right now.

https://review.openstack.org/#/c/228837/ is also needed

openstack-puppet-modules-2015.1.8-32.el7ost.noarch
[root@overcloud-controller-1 ~]# grep -i manila /etc/haproxy/haproxy.cfg 
[root@overcloud-controller-1 ~]#

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/RHBA-2015:2677