[messaging-topology-operator] Predictable/Prefixed username

[Lebvanih]

Hello,

We have a question regarding the messaging-topology-operator. I did a quick search, but couldn't find the answer.

We are using it in two different project, one where we only use one single user (so we don't really care about the username), and one where the team is telling us that they need around 40 users.

In the second project, they raised the point that if the username is generated randomly, this makes it hard for the support team or even the dev during debug, to identify to which application the user is linked while reading the rabbitmq-server logs. They would see the random name, the vhost and the queue, but this isn't always enough it seems for them to isolate quick.

From what we see in the two manifests (examples) there is, currently only two way of defining the user.

• https://github.com/rabbitmq/messaging-topology-operator/blob/main/docs/examples/users/user.yaml
• https://github.com/rabbitmq/messaging-topology-operator/blob/main/docs/examples/users/userPreDefinedCreds.yaml (the 3rd example is similar to this one).

The first one, had the advantage of generating the password randomly (so single object in our charts/deployment manifest) but the user can't be linked name given in the User CR for debugging just looking at the server logs.
The second one, we can customize the username, but we have to define the password.

Is there a way, to have the user generated in the first case prefixed by the Custom Resource definition name (or using the name directly) while keeping the password random, or to use the second method, but with a random password (I didn't try to leave the password empty in the secret, but the manifest mentioned to use both key)?

[coro]

Hi @Lebvanih, good question, it seems like there is not currently a way to predefine a username while randomly generating a password. I will add an issue to our backlog and the team will discuss it on Monday.

[Lebvanih]

Hello,

Ok! I will keep an eye on the ticket for now then.

[Lebvanih]

We tested the last version with the change included and this answer our needs. Ty!

[joshblease]

@Lebvanih, how did you solve this?
Currently we create a secret with a username and and empty password, then we create a RabbitUser with the importCredentialsSecret set to the username secret. This results in us having two secrets, one of which is pointless after user creation.

[ChunyiLyu]

Hi @joshblease, when you provide a importCredentialsSecret for a users.rabbitmq.com object, the operator will always create a new secret object that for its own use. The operator created secret will have users.rabbitmq.com as its owner reference and be garbage collected when users.rabbitmq.com is deleted. Secrets that you create and provide in importCredentialsSecret shouldn't be deleted after creation, unless you need the users.rabbitmq.com object that uses it.