Updating replicas does not update the ring builder files before triggering a rebalance

Bug #1713954 reported by James Hebden on 2017-08-30
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack swift-proxy charm
Medium
Unassigned

Bug Description

When updating the replicas setting, the ring builder files are not changed, and as such, the rebalance which is triggered by the config-changed hook reports that a rebalance is not required.

Reviewing the hook code, it seems that only changes to devices and/or nodes will instigate a change to the builder files, and that replicas is only considered when first initialising the rings.

Edward Hope-Morley (hopem) wrote :

Please provide the following:

  * your swift-proxy charm config

  * /var/log/juju/unit-swift-proxy-<id>.log from your leader unit (dump in a pastebin if possible)

  * output of 'swift-ring-builder /etc/swift/object.ring.gz'

Changed in charm-swift-proxy:
status: New → Incomplete
Edward Hope-Morley (hopem) wrote :

Ok I've had a look at the swift-proxy charm code to refresh my memory on how this is currently working and can confirm that replicas config is only used by the charm when the builders are first created so modifying this config option post-deployment will not have any effect. This is in fact the intended behaviour i.e. we just didn't add support for this to be changed. I assume that right now, users of this charm are manually updating the builders and re-spinning and syncing the rings manually. As previously mentioned this is not advisable since it will eventually conflict with the charms handling ring maintenance the next time it tries to update the rings in any way. So in my view the way forward is to extend what we have to be able to support updating this setting post-deployment while ensuring that we are able to do this without putting the cluster at-risk. I can see how this might seem suitable as a charm action but since the code that currently handles rings and builders is not controlled by actions (it actually pre-dates actions) and relies on charm config that actions can't set, it probably going to make most sense to extend the existing hook code. I intend to work on a patch to do this and document how it should be done so will post back once i have something.

Changed in charm-swift-proxy:
status: Incomplete → Confirmed
status: Confirmed → New
status: New → Confirmed
milestone: none → 17.11
importance: Undecided → Medium
James Page (james-page) on 2017-12-01
Changed in charm-swift-proxy:
milestone: 17.11 → 18.02
Ryan Beisner (1chb1n) on 2018-03-09
Changed in charm-swift-proxy:
milestone: 18.02 → 18.05
David Ames (thedac) on 2018-06-11
Changed in charm-swift-proxy:
milestone: 18.05 → 18.08
James Page (james-page) on 2018-09-12
Changed in charm-swift-proxy:
milestone: 18.08 → 18.11
David Ames (thedac) on 2018-11-20
Changed in charm-swift-proxy:
milestone: 18.11 → 19.04
David Ames (thedac) on 2019-04-17
Changed in charm-swift-proxy:
milestone: 19.04 → 19.07
David Ames (thedac) on 2019-08-12
Changed in charm-swift-proxy:
milestone: 19.07 → 19.10
David Ames (thedac) on 2019-10-24
Changed in charm-swift-proxy:
milestone: 19.10 → 20.01
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers