Groups of swift daemons are all forced to use the same config

Bug #1854718 reported by Liam Young on 2019-12-02
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Cloud Archive
Status tracked in Ussuri
Mitaka
High
Unassigned
Ocata
High
Unassigned
Queens
High
Unassigned
Rocky
High
Unassigned
Stein
High
Unassigned
Train
High
Unassigned
Ussuri
High
Unassigned
swift (Ubuntu)
Status tracked in Focal
Xenial
High
Unassigned
Bionic
High
Unassigned
Disco
High
Unassigned
Eoan
High
Unassigned
Focal
High
Unassigned

Bug Description

On swift storage servers there are three groups of services: account, container and object.

Each of these groups is comprised of a number of services, for instance: server, auditor, replicator etc

Each service has its own init script but all the services in a group are configured to use the same group config file eg swift-account, swift-account-auditor, swift-account-reaper & swift-account-replicator all use /etc/swift/account-server.conf.

Obviously this causes a problem when different services need different config. In the case of a swift cluster performing global replication the replication server need "
replication_server = true" where as the auditor needs "replication_server = false"

Liam Young (gnuoy) on 2019-12-02
description: updated
Corey Bryant (corey.bryant) wrote :

We may want to fix this along with https://bugs.launchpad.net/bugs/1800676. Sahid already took a stab at it a while back but that got delayed by me.

Liam, do you need this prior to ussuri?

Changed in swift (Ubuntu):
status: New → Triaged
importance: Undecided → High
Liam Young (gnuoy) wrote :

Hi Cory, the init script update is to support swift global replication. The upstream code and the proposed changes to the charm support the feature in mitaka so ideally the support would go right back to trusty-mitaka.

Corey Bryant (corey.bryant) wrote :

The switch to systemd unit files is a big change (LP: #1800676) which we can do at this point in the ussuri cycle, but I think we'll need to figure out how to adapt the existing sysvinit approach for SRUs.

Changed in swift (Ubuntu Eoan):
status: New → Triaged
importance: Undecided → High
Changed in swift (Ubuntu Disco):
status: New → Triaged
importance: Undecided → High
Changed in swift (Ubuntu Bionic):
status: New → Triaged
importance: Undecided → High
Changed in swift (Ubuntu Xenial):
status: New → Triaged
importance: Undecided → High

Hello Liam,

I probably missed something but in the account-server.conf file there are sections, normally we should be able to set a specific value for replication_server and that for swift server and replicator.

[account-server]
replication_server = true

[account-auditor]
replication_server = false

Can you share more details on how you think that should be working?

Thanks,
s.

Liam Young (gnuoy) wrote :

Hi Sahid,

In our deployment for swift global replication we have two account services.
One for local and one for replication:

# cat /etc/swift/account-server/1.conf
[DEFAULT]
bind_ip = 0.0.0.0
bind_port = 6002
workers = 1

[pipeline:main]
pipeline = recon account-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

[app:account-server]
use = egg:swift#account

[account-auditor]

[account-reaper]
#
# cat /etc/swift/account-server/2.conf
[DEFAULT]
bind_ip = 0.0.0.0
bind_port = 6012
workers = 1

[pipeline:main]
pipeline = recon account-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

[app:account-server]
use = egg:swift#account
replication_server = true
#

I believe these two config files are mutually exclusive as they have different
values for the same key in both the 'DEFAULT' and 'app:account-server'
sections.

Similarly, I believe the config file for the local account service is
incompatable with the local config file for the local container service.

# cat /etc/swift/account-server/1.conf
[DEFAULT]
bind_ip = 0.0.0.0
bind_port = 6002
workers = 1

[pipeline:main]
pipeline = recon account-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

[app:account-server]
use = egg:swift#account

[account-auditor]

[account-reaper]
#
# cat /etc/swift/container-server/1.conf
[DEFAULT]
bind_ip = 0.0.0.0
bind_port = 6001
workers = 1

[pipeline:main]
pipeline = recon container-server

[filter:recon]
use = egg:swift#recon
recon_cache_path = /var/cache/swift

[app:container-server]
use = egg:swift#container
allow_versions = true

[container-updater]

[container-auditor]

I believe these two config files are mutually exclusive as they have different
values for the same key in both the 'DEFAULT' and 'pipeline:main' sections.
sections.

Liam Young (gnuoy) wrote :

Sahid pointed out that the swift-init will traverse a search path and start a daemon for every config file it finds so no change to the init script is needed. Initial tests suggest this completely covers my use case. I will continue testing and report back. I will mark the bug as invalid for the moment. Thanks Sahid !

Changed in swift (Ubuntu Xenial):
status: Triaged → Invalid
Changed in swift (Ubuntu Bionic):
status: Triaged → Invalid
Changed in swift (Ubuntu Disco):
status: Triaged → Invalid
Changed in swift (Ubuntu Eoan):
status: Triaged → Invalid
Changed in swift (Ubuntu Focal):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers