Tenant Helm chart: Confusing use of configuration/configSecret

[stephan2012]

Expected Behavior

The current Tenant Helm chart shows a confusing mix of .tenant.configuration.name (required by the Operator) and .tenant.configSecret.name (required by the Tenant chart). However, both values shall reference the same Kubernetes Secret.

To make the chart work, you have to configure both.

Example:

  configuration:
    name: foobar
  configSecret:
    name: foobar
    existingSecret: true

Current Behavior

This is how the template currently looks like:

  ###
  # The Kubernetes secret name that contains MinIO environment variable configurations.
  # The secret is expected to have a key named config.env containing environment variables exports.
  configuration:
    name: myminio-env-configuration
  ###
  # Root key for dynamically creating a secret for use with configuring root MinIO User
  # Specify the ``name`` and then a list of environment variables.
  #
  # .. important::
  #
  #    Do not use this in production environments.
  #    This field is intended for use with rapid development or testing only.
  #
  # For example:
  #
  # .. code-block:: yaml
  #
  #    name: myminio-env-configuration
  #    accessKey: minio
  #    secretKey: minio123
  #
  # configSecret:
  #   name: myminio-env-configuration
  #   accessKey: minio
  #   secretKey: minio123
  ###
  # If this variable is set to true, then enable the usage of an existing Kubernetes secret to set environment variables for the Tenant.
  # The existing Kubernetes secret name must be placed under .tenant.configuration.name e.g. existing-minio-env-configuration
  # The secret must contain a key ``config.env``.
  # The values should be a series of export statements to set environment variables for the Tenant.
  # For example:
  #
  # .. code-block:: shell
  #
  #    stringData:
  #       config.env: |-
  #         export MINIO_ROOT_USER=ROOTUSERNAME
  #         export MINIO_ROOT_PASSWORD=ROOTUSERPASSWORD
  #
  #   existingSecret: false

Possible Solution

Unify both by going for .tenant.configuration.name only.

Steps to Reproduce (for bugs)

See chart.

Context

Upgrading chart from v5.x to v6.0.2.

Regression

No.

Your Environment

• Version used (minio-operator): v6.0.2
• Environment name and version (e.g. kubernetes v1.17.2): v1.29.7
• Server type and version: Debian GNU/Linux 12 (Bookworm)
• Operating System and version (uname -a): Linux n0251 6.9.7+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1~bpo12+1 (2024-07-03) x86_64 GNU/Linux
• Link to your deployment file: N/A

(Possibly) Related: #2255, #2279

[stephan2012]

By the way, omitting .tenant.configuration.name results in the error below.

$ kubectl logs -n minio-tenant minio-tenant-pool-0-0 -c validate-arguments 
2024/08/19 19:45:48 validator.go:72: secrets "myminio-env-configuration" not found
panic: secrets "myminio-env-configuration" not found

goroutine 1 [running]:
github.com/minio/operator/sidecar/pkg/validator.Validate({0x7fff1edbfb98, 0xc})
        github.com/minio/operator/sidecar/pkg/validator/validator.go:73 +0x61c
main.startValidator(0xc000033401?)
        github.com/minio/operator/sidecar/cmd/sidecar/validate.go:41 +0x2c
github.com/minio/cli.HandleAction({0x1978e20?, 0x1e3c690?}, 0x8?)
        github.com/minio/[email protected]/app.go:492 +0x70
github.com/minio/cli.Command.Run({{0x1d2bea0, 0x8}, {0x0, 0x0}, {0x2e22820, 0x1, 0x1}, {0x1d56f74, 0x25}, {0x0, ...}, ...}, ...)
        github.com/minio/[email protected]/command.go:242 +0x938
github.com/minio/cli.(*App).Run(0xc000103dc0, {0xc000136040, 0x4, 0x4})
        github.com/minio/[email protected]/app.go:260 +0xa7b
main.main()
        github.com/minio/operator/sidecar/cmd/sidecar/main.go:129 +0x5e

[ramondeklein]

Duplicate of #2255.