Default partition-power is too small

[Erlon R. Cruz]

The partition power is used to build the swift rings and define the
granularity of the data copies. The total number of partitions in
the cluster will be 2^partition-power. The recommended number of
partitions of a cluster is a minimum of 100 per disk, and it should
be considered any future cluster expansion, since changing this value
is not trivial after the cluster initialization.

Currently, the default value is 8, and given that 2^8 is only 256,
this number will lead to a sub-optimal configuration even on test
deployments with 3+ disks, not to say on a production where disks can
surpass the hundreds and this will lead to a very unbalanced cluster.

We had some production clusters that were wrongly set to the default
value and that resulted in an awfully unbalanced cluster. We should
avoid that to happen again.

[Erlon R. Cruz (sombrafam)]

As I mentioned offline, the only drawback of using a big value would be memory consumption, but that would be in the MBs, and wouldn't affect performance. Documentation on the recommended values is not present in the official documentation, but there are some good presentations[1] providing info on that.

[1] https://youtu.be/LzaQKKp58JI?t=606

[Erlon R. Cruz (sombrafam)]

Fix: https://review.opendev.org/c/openstack/charm-swift-proxy/+/784813

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/charm-swift-proxy/+/784813
Committed: https://opendev.org/openstack/charm-swift-proxy/commit/54583248b9510ba0d17313dea044b402953f4e94
Submitter: "Zuul (22348)"
Branch: master

commit 54583248b9510ba0d17313dea044b402953f4e94
Author: Erlon R. Cruz <email address hidden>
Date: Mon Apr 5 15:31:12 2021 -0300

    Bump default swift partition power

    The partition power is used to build the swift rings. The total
    number of partitions in the cluster will be 2^partition-power.
    The recommend number of partitions of a cluster is a minimum of 100
    per disk. Given that 2^8 is only 256, this number will lead to a sub-
    optimal configuration even on test deployments, not to say on production
    where disks can surpass the hundreds, and this will lead to a very
    unbalanced cluster.

    Closes-bug: #1931286
    Change-Id: Ifdf2b96f27f18bc64549c40d8fa47474f8eb59c8