New S3 Configuration breaks prior S3 configuration and is missing uploadPartSize

[acidicX]

Describe your Issue

I've used the S3 integration before "manually" via configs.s3.config.php, now the helm chart upgrade (v5.4.0) fails because it's already defined

Logs and Errors

Helm upgrade failed: error while running post render on files: map[string]interface {}(nil): yaml: unmarshal errors: line 168: mapping key "s3.config.php" already defined at line 23

Describe your Environment

• Kubernetes distribution: k8s

• Helm Version (or App that manages helm):

• Helm Chart Version: 5.4.0

• values.yaml:

configs:
        s3.config.php: |-
          <?php
          $CONFIG = array (
            'objectstore' => array(
              'class' => '\\OC\\Files\\ObjectStore\\S3',
              'arguments' => array(
                'hostname'         => 's3.eu-central-2.wasabisys.com',
                'bucket'           => '...',
                'autocreate'       => false,
                'key'              => '...',
                'secret'           => '...',
                'region'           => 'eu-central-2',
                'use_ssl'          => true,
                'use_path_style'   => false,
                'uploadPartSize'   => '2097152000'
              )
            )
          );

Additional context, if any

1. It would be nice if such a change would be marked as a breaking change next time
2. The chart should respect the manually set configuration
3. The new options are missing uploadPartSize, which is required to be set there for some reason on S3 storage, so I can't even switch to the new configuration style

[provokateurin]

Sorry for this breaking change :/ I think your config should continue to work fine by just renaming the config file. Could you open a PR for the uploadPartSize so that it is present and allows you to switch to the new configs?

[acidicX]

@provokateurin thanks for the quick response, I can try to open a PR but I'm no expert in helm charts and I can't test the change locally at the moment.

[jessebot]

🙇 sorry about that, @acidicX!

I actually submitted https://github.com/nextcloud/docker/pull/2271 upstream for these changes, but I'll submit one here as well now!

[jessebot]

In the meantime, you should be able to disable the default config being deployed by setting nextcloud.defaultConfigs.s3.config.php=false, or via values.yaml:

nextcloud:
  defaultConfigs:
    s3.config.php: false

Can you confirm if this works? Because if that doesn't work either, we should also try to fix that. Sorry again for the inconvenience regardless 🙏

[jessebot]

Sorry for the rapid updates, but if #614 gets merged, it will close this Issue automatically. That doesn't mean we can't still help you if other things are still broken here though, so please just let us know if that's the case and we can reopen this issue for you if it gets closed 🙏

Update: We're going to wait till nextcloud/docker reviews/merges our upstream PR, https://github.com/nextcloud/docker/pull/2271 before merging #614

[acidicX]

@jessebot thanks for the fast reaction, I can confirm that the workaround (nextcloud.defaultConfigs.s3.config.php=false) works for me :) I've been able to upgrade and everything seems to work fine.

[MaksonHerson]

Hello @jessebot , @acidicX ! I got the same trouble with already defined mapping key for s3.config.php file. I used:

nextcloud:
  defaultConfigs:
    s3.config.php: false

and it does not work for me. I try for 5.4.0 and 5.5.2 chart versions.

I was able to fix it with renaming my s3 config file to:

configs:
        s33.config.php:

Unfortunately it steel needs to be fix. :(

Essential part of my helmrelease file:

    defaultConfigs:
      s3.config.php: false
      swift.config.php: false
    objectStore:
      s3:
        enabled: true
        ssl: true
        port: ***
        region: ***
        usePathStyle: true
        autoCreate: true
        existingSecret: nextcloud-values
        secretKeys:
          host: hostname
          accessKey: key
          secretKey: secret
          bucket: bucket