Description of problem: After 7.1 -> 7.2 update manilla section shows up in haproxy. Actual results: After the update in /etc/haproxy/haproxy.cfg listen manila server overcloud-controller-0 192.0.2.10:8786 check fall 5 inter 2000 rise 2 server overcloud-controller-1 192.0.2.12:8786 check fall 5 inter 2000 rise 2 server overcloud-controller-2 192.0.2.13:8786 check fall 5 inter 2000 rise 2 Expected results: There is no manila section in the haproxy config. Additional info: I'm not sure if this is actually a bug or it comes by default with the 7.2 templates but I didn't expect it to be there as my overcloud didn't run Manila.
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