s3-lib sets 'bucket: relations-$id' on requester side, makes it incompatible with s3-integrator track 2/edge rev167

[taurus-forever]

Issue

Bugreport to Postgresql: canonical/postgresql-operator#1043 (PG failed to work with s3-integrator 2/edge rev167)

Steps to reproduce

1. juju deploy mysql # or postgresql
2. juju deploy s3-integrator --channel 2/edge
3. juju config s3-integrator endpoint="https://s3.amazonaws.com" region="us-east-1" bucket="mybucket" path="mypath"
4. jujusecret=$(juju add-secret s3-integrator access-key=myaccess secret-key=mysecret)
5. juju grant-secret ${jujusecret} s3-integrator
6. juju config s3-integrator credentials=${jujusecret}
7. juju relate s3-integrator mysql

Actual behavior

Error on MySQL side:

unit-mysql-0: 16:12:30 INFO unit.mysql/0.juju-log Listing subdirectories from S3 bucket=relation-9, path=alutay_1755180485                                                                                                                              
unit-mysql-0: 16:12:31 ERROR unit.mysql/0.juju-log Bucket relation-9 does not exist  

It happens because s3-integrator returned bucket as relations-9 and not pre-configured mybucket.
Which happends because s3-lib LIBAPI=6 set bucket = relation-id here.

Expected behaviour

S3 library should NOT set bucket name by default, as it is optional.

Versions

Juju CLI: 3.6.8
Juju agent: 3.6.8

ubuntu@juju366:~$ juju status
Model   Controller  Cloud/Region         Version  SLA          Timestamp
test67  lxd         localhost/localhost  3.6.8    unsupported  17:13:09+02:00

App         Version          Status  Scale  Charm          Channel     Rev  Exposed  Message
mysql       8.0.41-0ubun...  active      1  mysql          8.0/stable  366  no       
postgresql  16.9             active      1  postgresql     16/edge     874  no       
s3-new                       active      1  s3-integrator  2/edge      167  no       

Unit           Workload  Agent  Machine  Public address  Ports           Message
mysql/0*       active    idle   1        10.176.3.183    3306,33060/tcp  Primary
postgresql/0*  active    idle   0        10.176.3.223    5432/tcp        Primary
s3-new/0*      active    idle   3        10.176.3.82                     

Machine  State    Address       Inst id        Base          AZ  Message
0        started  10.176.3.223  juju-cbd943-0  ubuntu@24.04      Running
1        started  10.176.3.183  juju-cbd943-1  ubuntu@22.04      Running
3        started  10.176.3.82   juju-cbd943-3  ubuntu@24.04      Running

Additional context

Proposal: change the presidency order in s3-integrator channel 2/edge.
Use requester-bucket value IF no bucket set in s3-charm-config only.
It will keep compatibility with old behavior, allows requester charm request default bucket name (e.g. workdpress charm may request wordpress bucket by default) and Juju Admins can overwrite the request using s3-integrator config bucket='wordpress-test-bucket'.

If bucket is empty in relation and config, either:

• return no bucket in relation => requester charm decide on name
• continue returning relation-$id like now

P.S. bucket name in relation sets by requestor and not insistor ;-)

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/DPE-7971.

This message was autogenerated

[theoctober19th]

I'm thinking about this for the past few days, and have concluded that this be fixed in two ways:

1. Fix this in s3_lib v0 (such that the requirer side of the lib never puts bucket parameter automatically if not provided) -- however this will make the new adopters of s3_lib v0 incompatible with s3-integrator 1/ channel because channel 1/ uses the same s3_lib v0, where the library makes an assumption that bucket field is always filled to start sharing the provider data.

2. Fix this on s3_lib v1 such that the provider side of the lib first differentiates the lib version on the requester's requirer side of the lib, and if it detects the requester is using v0 of the lib, it simply disregards the bucket field.
   This can be done by detecting the field requested-secrets in the relation databag. This field should not exist if the charm uses v0 of the lib because v0 doesn't support Juju secrets.

For me (1) is not really an option and I prefer (2) because this change if done in v0 is a breaking change, which means it cannot be introduced in the same LIBAPI=0.

So the best path for me here is to fix this in s3_lib v1, have a new release of s3-integrator on 2/edge channel, and with that s3-integrator this problem should not exist.

[mcarvalhor]

This is also affecting other charms and not only PostgreSQL. For example, COS HA is also affected.
canonical/object-storage-integrator#41

[theoctober19th]

Hi @taurus-forever and @mcarvalhor, the PR canonical/object-storage-integrator#43 should solve this. You can test this on rev 220 of s3-integrator in the 2/edge channel.

I'm currently working on reversing the priority order of the config-bucket vs relation-bucket (it has been recently changed in the spec DA 179) and thus please note that the precedence order you find in 220 is going to be changed in next revision. However, since in your test you use only config-bucket and do not set the relation-bucket, this change is not much relevant in your case.

[theoctober19th]

Hi @taurus-forever and @mcarvalhor, the revision 225 on s3-integrator 2/edge now has the correct priority order of buckets and this issue has also been fixed on that revision. Please let me know if you find the problem still persists on that revision.

[skatsaounis]

Hello folks,

A question for @taurus-forever: What are the next steps here so that we can use track 2 of the s3-integrator with postgresql charm track 16?

A question for @theoctober19th: What is missing in general from the s3-integrator 2/edge to promote to 2/stable?

[theoctober19th]

What is missing in general from the s3-integrator 2/edge to promote to 2/stable?

Hi @skatsaounis, we announced 2/candidate just earlier today, please give it a try and provide feedbacks. We aim at leaving the candidate out for a few weeks to collect feedback, with the outlook to have a stable release by the end of the cycle.

Discourse Announcement: https://discourse.charmhub.io/t/new-object-storage-and-auth-integrators-now-in-candidate/20187