user secret not updated when creating cluster with default_user config

[heimdull]

Describe the bug

When using the default_user/default_pass the kubernetes secret is not updated. When using the messaging-topology-operator with a set default_user you will get a 401 because it looks at the secret.

To Reproduce

Steps to reproduce the behavior:
deploy cluster with this additionalConfig:

spec:
rabbitmq:
additionalConfig: |
default_user=guest
default_pass=guest

Expected behavior
secret is used by other operators so it needs to be updated

Version and environment information

latest operator

[ChunyiLyu]

@heimdull This is a known limitation with the operator. I could treat this as a feature request and discuss with the rest of the team.

Meanwhile, for a workaround, you could either update the secret manually yourself after the rmq is created. Alternatively, you can create a default user secret first with the expected username and password before you create the rabbitmqcluster. For example, if your rabbitmqcluster name is sample, you can create a secret, in the same namespace called sample-default-user:

apiVersion: v1
kind: Secret
metadata:
  name: sample-default-user
type: Opaque
stringData:
  username: guest-user
  password: guest-pass
  default_user.conf: |
    default_user = guest-user
    default_pass = guest-pass

Then you can create the rabbitmqcluster. There is no need to set the username&password in the rmq manifest with this approach.

[ablease]

Waiting for response from issue creator, was this workaround suitable for them?

[heimdull]

This works for us. After discovering your other operator that could create users we used that to generate the users we needed.

[ChunyiLyu]

@heimdull thanks for replying. I will close this issue for now.

[lukebakken]

Re-opening so that this feature can be planned at some point.

[piotrlaczykowski]

Re-opening so that this feature can be planned at some point.

It would be nice

[winston0410]

@heimdull This is a known limitation with the operator. I could treat this as a feature request and discuss with the rest of the team.

Meanwhile, for a workaround, you could either update the secret manually yourself after the rmq is created. Alternatively, you can create a default user secret first with the expected username and password before you create the rabbitmqcluster. For example, if your rabbitmqcluster name is sample, you can create a secret, in the same namespace called sample-default-user:

apiVersion: v1
kind: Secret
metadata:
  name: sample-default-user
type: Opaque
stringData:
  username: guest-user
  password: guest-pass
  default_user.conf: |
    default_user = guest-user
    default_pass = guest-pass

Then you can create the rabbitmqcluster. There is no need to set the username&password in the rmq manifest with this approach.

Is it possible that the CRD accept the secret instead, say in spec.cluster.defaultUserConfig, instead of relying on the name of the secret? For using tools like Kustomize, that would generate hash for secret based on its content, having that option would allow us to link the secret with the CRD properly.

[Zerpet]

We can't support a Secret instead of the in-lined config without breaking changes, or without additional complexity e.g. what happens when default user/pass and a default user config secret are provided?

I will keep this issue to address the problem described by the OP. When default user/pass is present in additionalConfig, those values will be injected in the generated Secret for default user and password.