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:
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
~~~
https://github.com/openstack/tripleo-heat-templates/blob/master/extraconfig/tasks/yum_update.sh
It should be noted that the timeouts are correct. I believe this was added as a workaround to bring them up to match what was expected in the puppet in later versions.
https:/