This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1287817 - After 7.1 -> 7.2 update manila section shows up in haproxy
After 7.1 -> 7.2 update manila section shows up in haproxy
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-puppet-modules (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
urgent Severity high
: z3
: 7.0 (Kilo)
Assigned To: Lukas Bezdicka
Marius Cornea
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-02 13:36 EST by Marius Cornea
Modified: 2015-12-21 12:12 EST (History)
12 users (show)

See Also:
Fixed In Version: openstack-puppet-modules-2015.1.8-32.el7ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-21 12:12:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marius Cornea 2015-12-02 13:36:27 EST
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.
Comment 2 Marios Andreou 2015-12-03 09:42:24 EST
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
Comment 3 Marios Andreou 2015-12-03 09:53:47 EST
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
Comment 4 James Slagle 2015-12-07 11:46:07 EST
Emilien, moving this one to opm as it looks like it's caused by a bad rebase/patch
Comment 5 Emilien Macchi 2015-12-07 16:02:50 EST
Thanks James, that is true the rebase did not work correctly, my team is taking care of the bug right now.
Comment 6 Lukas Bezdicka 2015-12-08 05:47:42 EST
https://review.openstack.org/#/c/228837/ is also needed
Comment 9 Marius Cornea 2015-12-12 11:42:41 EST
openstack-puppet-modules-2015.1.8-32.el7ost.noarch
[root@overcloud-controller-1 ~]# grep -i manila /etc/haproxy/haproxy.cfg 
[root@overcloud-controller-1 ~]#
Comment 11 errata-xmlrpc 2015-12-21 12:12:17 EST
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

Note You need to log in before you can comment on or make changes to this bug.