Bug 1439952

Summary: openstack minor update - list_updates=$(yum list updates) never returns empty string
Product: Red Hat OpenStack Reporter: Andreas Karis <akaris>
Component: openstack-tripleo-heat-templatesAssignee: Alex Schultz <aschultz>
Status: CLOSED ERRATA QA Contact: Yurii Prokulevych <yprokule>
Severity: medium Docs Contact:
Priority: high    
Version: 10.0 (Newton)CC: aschultz, mburns, ohochman, rhel-osp-director-maint, tvignaud
Target Milestone: gaKeywords: Triaged
Target Release: 12.0 (Pike)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-7.0.0-0.20170616123155.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1440213 (view as bug list) Environment:
Last Closed: 2017-12-13 21:22:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1440213, 1440217    

Description Andreas Karis 2017-04-06 23:43:16 UTC
Description of problem:
openstack minor update - list_updates=$(yum list updates) never returns empty string

/usr/share/openstack-tripleo-heat-templates/extraconfig/tasks/yum_update.sh
~~~
(...)
list_updates=$(yum list updates)

if [[ "$list_updates" == "" ]]; then
    echo "No packages require updating"
    exit 0
fi
(...)
~~~

The if condition never fulfills!

This can be easily tested:
~~~
[root@undercloud-4 ~]# list_updates=$(yum list updates)
[root@undercloud-4 ~]# echo $list_updates
Loaded plugins: search-disabled-repos
~~~

Expected results:
This should be `yum -q list updates`, and the if condition will be reached

Additional info:

Comment 1 Andreas Karis 2017-04-06 23:47:33 UTC
As a side note, related to this:

We fix the pacemaker timeouts, but **after** the if condition which leads to an exit. Only **then* do we increase the timeouts on pacemaker resources, but **never** (at least not in this script) are we setting them back. If this is a global workaround, this will work now, because the if condition is never true. If the increased timeouts are needed elsewhere in the update process, though, then they need to be before the if condition, or the timeouts will not be adjusted if the above bug is fixed.
~~~
# Fix the redis/rabbit resource start/stop timeouts. See https://bugs.launchpad.net/tripleo/+bug/1633455
# and https://bugs.launchpad.net/tripleo/+bug/1634851
if [[ "$pacemaker_status" == "active" && \
      "$(hiera -c /etc/puppet/hiera.yaml bootstrap_nodeid)" = "$(facter hostname)" ]] ; then
    if pcs resource show rabbitmq | grep -E "start.*timeout=100"; then
        pcs resource update rabbitmq op start timeout=200s
    fi
    if pcs resource show rabbitmq | grep -E "stop.*timeout=90"; then
        pcs resource update rabbitmq op stop timeout=200s
    fi
    if pcs resource show redis | grep -E "start.*timeout=120"; then
        pcs resource update redis op start timeout=200s
    fi
    if pcs resource show redis | grep -E "stop.*timeout=120"; then
        pcs resource update redis op stop timeout=200s
    fi
fi
~~~

Comment 2 Alex Schultz 2017-04-07 15:09:24 UTC
As mentioned in the upstream bug, comment #1 is not a problem because those match the expected settings. I believe the shell script was used when updating nodes to prevent the update from hanging and pre-setting the timeouts to the new correct values.

Comment 3 Andreas Karis 2017-04-07 16:29:49 UTC
Thanks!

Comment 10 errata-xmlrpc 2017-12-13 21:22:29 UTC
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/RHEA-2017:3462