Nova-Compute Operator: nova-compute doesn't respect amqp name change
Summary
The nova-compute-operator creates nova-compute conf with new amqpuser name schema and doesn't change already present MQ User with old naming schema.
nova-compute errors with
Login was refused using authentication mechanism AMQPLAIN
Detailed Description
This problem occurs when updating to https://gitlab.com/yaook/operator/-/releases/v1.2.1 with already created MQ-Users but not yet created nova-computes. (since !3361 (merged))
nova-compute-operator will then create the nova-compute sts with the wrong amqpuser
Steps to reproduce the issue
- Redeploy a lot of Nodes
- MQ Users are created by nova-compute-operator
- Scale nova-compute-operator deployment to 0 replicas
- Delete the config secret of the nova-compute (state.yaook.cloud/component=compute_config)
- Yaook update (+ scale nova-compute-operator to 1 replica)
- New Operator creates nova-compute
Result
nova-compute in CrashLoopBackoff
File \"/usr/local/lib/python3.10/dist-packages/amqp/abstract_channel.py\"
, line 156, in dispatch_method", " listener(*args)", " File \"/usr/local/lib/python3.10/dist-packages/amqp/connection.py\", line 668, in _on_close", " raise error_for_code(reply_code, reply_text,", "amqp.exceptions.AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN.
Expected Result
nova-compute-operator deletes/changes old MQUsers and adepts them to new naming-schema before creating the nova-compute
Additional Information
Workaround
Delete the AMQPUsers for the compute node (without finalizer removal) and the nova-compute-operator will recreate the AMQPUser with the correct username.
kubectl -n yaook get sts -L state.yaook.cloud/parent-name nova-compute-xzljn
# -> get compute node name
kubectl -n yaook get amqpuser -l state.yaook.cloud/parent-name=cmp42.yaook.cloud
kubectl -n yaook delete amqpuser -l state.yaook.cloud/parent-name=cmp42.yaook.cloud
Proposal
Use the existing SingleAMQPUser to extract the RabbitMQ username.
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this issue are to be interpreted in the spirit of RFC 2119, even though we're not technically doing protocol design.