[Bug 1588462] Re: Status set multiple times in OpenStack charms with optional relations
Alex Kavanagh
1588462 at bugs.launchpad.net
Thu Jun 16 16:54:54 UTC 2016
The initially listed charms have been checked, and the rest of the
charms reviewed for the multiple status_set issue:
charm-ceilometer - OK
charm-ceilometer-agent - OK
charm-ceph - different implementation - OK
charm-ceph-mon - different implementation - OK
charm-ceph-osd - different implementation - OK
charm-ceph-radosgw - DONE
charm-cinder - DONE
charm-cinder-backup - no implementation of assess_status - OK
charm-cinder-ceph - no implementation of assess_status - OK
charm-glance - DONE
charm-hacluster - no implementation of assess_status - OK
charm-heat - no implementation of assess_status - OK
charm-keystone - DONE
charm-lxd - different implementation of assess_status - OK
charm-neutron-api - DONE
charm-neutron-api-odl - no implementation of assess_status - OK
charm-neutron-gateway - DONE
charm-neutron-openvswitch - has a slightly different implementation - OK
charm-nova-cloud-controller - DONE
charm-nova-compute - has a slightly different implementation - OK
charm-odl-controller - no implementation of assess_status - OK
charm-openstack-dashboard - no optional interfaces - OK
charm-openvswitch-odl - reactive charm with no assess_status implementation - OK
charm-percona-cluster - has different implementation - not affected - OK
charm-rabbitmq-server - Not OK - has different multiple-status-set problem !!!
charm-swift-proxy - OK - but needs an edit to fix bad function names
charm-swift-storage - has simple implementation of assess_status - OK
charm-tempest - new, so has no assess_status() implementation yet. - OK
This pulls out that the rabbitmq-server charm needs to be resolved as
well.
--
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 multiple times in OpenStack charms with optional relations
Status in ceph-radosgw package in Juju Charms Collection:
Fix Committed
Status in cinder package in Juju Charms Collection:
Fix Committed
Status in glance package in Juju Charms Collection:
Fix Committed
Status in keystone package in Juju Charms Collection:
Fix Committed
Status in neutron-api package in Juju Charms Collection:
Fix Committed
Status in neutron-gateway package in Juju Charms Collection:
Fix Committed
Status in nova-cloud-controller package in Juju Charms Collection:
Fix Committed
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