[Bug 1588462] Related fix merged to charm-glance (master)
OpenStack Infra
1588462 at bugs.launchpad.net
Wed Jun 8 18:15:48 UTC 2016
Reviewed: https://review.openstack.org/325650
Committed: https://git.openstack.org/cgit/openstack/charm-glance/commit/?id=1ab2c809ad7251f6d8a30c053d8c7818ac051547
Submitter: Jenkins
Branch: master
commit 1ab2c809ad7251f6d8a30c053d8c7818ac051547
Author: Alex Kavanagh <alex at ajkavanagh.co.uk>
Date: Sun Jun 5 12:57:53 2016 +0000
Fix for status-set race - related to bug 1588462
This change fixes the obvious race for a status_set() between
check_optional_interfaces() and assess_status() as the later calls the former
which calls status_set(), returns the status, which is then potentially set
again by the assess_status() function. This cleans up the code so that only a
single status_set() is performed when calling assess_status().
Change-Id: I06efbcaade8f0c99b5931104e6887d24cb10e35a
Related-Bug:#1588462
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to cinder in Juju Charms Collection.
Matching subscriptions: charm-bugs
https://bugs.launchpad.net/bugs/1588462
Title:
Status set race condition in OpenStack charms with optional relations
Status in ceph-radosgw package in Juju Charms Collection:
New
Status in cinder package in Juju Charms Collection:
New
Status in glance package in Juju Charms Collection:
New
Status in keystone package in Juju Charms Collection:
New
Status in neutron-api package in Juju Charms Collection:
New
Status in neutron-gateway package in Juju Charms Collection:
New
Status in nova-cloud-controller package in Juju Charms Collection:
New
Bug description:
In charms that call assess_status() on every hook execution and that have
optional relations there are two places where status_set() is called in
set_os_workload_status() and make_assess_status_func()'s _assess_status_func()
leading to a race condition in which a status may be overwritten.
For charms like nova-cloud-controller where strangely we call
set_os_workload_status() on each hook execution instead of assess_status() we
only see this during pause and resume actions which do call assess_status().
Regardless of __if__ you hit the race condition you can see the problem simply
using print statements and an update-status hook run:
'STATUS SET IN set_os_workload_status', 'active', 'Unit is ready'
'STATUS SET IN _assess_status_func()', 'active', 'Unit is ready'
If the first happened to be different the second would clobber it.
In the set_os_workload_status() stack a comparison is made against the current
status before setting status. The assess_status() stack needs to do the same
possibly by calling set_os_workload_status() itself.
The goal should be to have a single canonical source for status_set.
This will affect all OpenStack charms that have optional relations.
To manage notifications about this bug go to:
https://bugs.launchpad.net/charms/+source/ceph-radosgw/+bug/1588462/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list