There are several errors related to the swift replication service.
The swift storage charm is not properly restarting the services
after configuration changes, the correct object_lockup_timeout
value (that per the behaviour observerd in our environments must
be greater than object_rsync_timeout) and we also needed to fix
the object replicator config file to honor the
object-handoffs-first configuration.
This patch along with the swift proxy-change should fix the
currently known replication problems.
Closes-bug: #1903762
Depends-on: I87eb23de94e3f2f5b06d44df1f8bd9d2324456a0
Change-Id: I87eb23de94e3f2f5b06d44df1f8bd9d2324c8470
In order to prevent disks from filling up, add the option to configure
fallocate_reserve parameter in account-server.conf,
container-server.conf, and object-server.conf, as described in
https://docs.openstack.org/swift/latest/admin_guide.html#preventing-disk-full-scenarios
This change adds the config option file-allocation-reserve with a
default of 0.
Change-Id: Ib396a151250bb8d1733f9b5b9cab7eb506c9f6c6
Closes-Bug: 1872069
Swift default is used if no config provided.
As per swift docs, if node_timeout is set,
http_timeout ensured to be greater than
node_timeout.
Change-Id: Idf5945a6c2f64fcad8f2ab7cb137f1ce1f1dc424
Closes-Bug: #1878657
In extreme cases of object rebalance or node failure, swift environments
with millions of objects may have a hard time with objects landing in
handoff or misplaced partitions and the operator of the cloud may need
to prioritize migrating data in handoff partitions back to primary
partitions over the 3 primary partitions replicating amongst each other.
To allow for this, the object-server.conf [object-replicator]
configuration can have handoffs_first set to True which will force
the object-replicators to focus on handoff partitions before syncing
primary partitions for any given object partition.
Change-Id: I8b44c287567a0e6d634def0b13baf0fe4ad4aa7b
Closes-Bug: 1878087
This patchset adds a support for Swift Global Cluster feature as
described at:
https://docs.openstack.org/swift/latest/overview_global_cluster.html
It allows specifying 'region' config option as part of the deployment.
Theregion is reflected later on in the Swift rings.
Change-Id: I11b6c7802e5bfbd61b06e4d11c65804a165781b6
Partial-Bug: 1815879
Needed-By: I406445493e2226aa5ae40a09c9053ac8633a46e9
Add new secrets-storage relation to vault, supporting the
use of block device encryption using dm-crypt/vaultlocker.
Prepared devices are now recorded in the local unit kv
store; this information is used to provide a list of
configured block devices to the swift-proxy charm,
rather than the previous best guess provided by
determine_block_devices. This allows us to use the
dm-crypt device name, rather than the underlying
block device.
Encrypted block devices are unlocked on boot using
vaultlocker-decrypt systemd units (enabled by vaultlocker);
/etc/fstab entries for such devices make use of a
x-systemd.requires option to ensure that the block device
is unlocked prior to attempting to mount it.
Add new storage binding to allow charm to be used with
Juju storage.
Add new ephemeral-unmount configuration option to allow
cloud ephemeral storage to be used for testing purposes;
update functional testing to use this option. The behaviour
of 'overwrite' was changed to accomodate the use of
encrypted block devices.
Change-Id: I9b3f8cd2de412ee96e0139dba4d4abdf998ecaf2
By default, statsd metrics can be sent by the swift account,
container and object storage services for diagnostic and
monitoring purposes, but are disabled by default. This change exposes
charm config settings that allow it to be enabled by setting
'statsd_host' to a non-empty value. 'statsd_port' and
'statsd_sample_rate' are also supported for changing the destination
port and rate at which metrics are collected.
Closes-Bug: #1729770
Change-Id: If1bf3ced8a9ed07af81f352eb0263659d147e3aa
Adds the rsync_timeout option to to object-server.conf, so we can adjust
it away from the default of 900s.
If there are a number of large partitions needing replication,
occasionally one needs to adjust the timeout in order to allow the rsync
to complete rather than timeout and retry.
Change-Id: I2d895741cb0528836a675deb6399005a5bf59ab5
Closes-bug: 1702039
Erlon R. Cruz