rotate password action updates relation data in private-address field
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Canonical Juju |
Invalid
|
Undecided
|
Unassigned | |||
OpenStack RabbitMQ Server Charm | Status tracked in Trunk | |||||
Jammy |
Triaged
|
High
|
Unassigned | |||
Trunk |
Fix Committed
|
High
|
Unassigned |
Bug Description
I have a cross-controller integration between a k8s application and rabbitmq. After I run the rotate-
$ juju show-unit flask-rabbitmq/0
flask-rabbitmq/0:
opened-ports: []
charm: local:jammy/
leader: true
life: alive
relation-info:
- relation-id: 5
endpoint: amqp
cross-model: true
related-
application
related-units:
rabbitmq-
in-scope: true
data:
hostname: 10.33.194.148
password: 54ymh56NPnbcb5b
Steps to reproduce:
- create integration
- run the action
- look in the relation data bag of the k8s unit
This problem was observed for a cross-controller integration between a k8s cloud and openstack cloud, and
could be reproduced inside a multipass vm.
rabbitmq-server channel 3.9/stable rev 183
k8s cloud env: juju 2.9.44
openstack cloud env: 3.1.6
multipass env: juju 3.1.7 for both controllers
╰─$ juju status --relations
Model Controller Cloud/Region Version SLA Timestamp
reactive-runner lxd localhost/localhost 3.1.7 unsupported 13:25:09+01:00
App Version Status Scale Charm Channel Rev Exposed Message
rabbitmq-server 3.9.13 active 1 rabbitmq-server 3.9/stable 183 no Unit is ready
Unit Workload Agent Machine Public address Ports Message
rabbitmq-server/0* active idle 4 10.33.194.148 5672,15672/tcp Unit is ready
Machine State Address Inst id Base AZ Message
4 started 10.33.194.148 juju-963f30-4 ubuntu@22.04 Running
Offer Application Charm Rev Connected Endpoint Interface Role
rabbitmq-server rabbitmq-server rabbitmq-server 183 1/1 amqp rabbitmq provider
Integration provider Requirer Interface Type Message
rabbitmq-
rabbitmq-
╰─$ juju switch microk8s; juju status --relations
Model Controller Cloud/Region Version SLA Timestamp
flask microk8s microk8s/localhost 3.1.7 unsupported 13:29:40+01:00
SAAS Status Store URL
rabbitmq-server active lxd admin/reactive-
App Version Status Scale Charm Channel Rev Address Exposed Message
flask-rabbitmq active 1 flask-rabbitmq 6 10.152.183.225 no
Unit Workload Agent Address Ports Message
flask-rabbitmq/0* active idle 10.1.225.163
Integration provider Requirer Interface Type Message
flask-rabbitmq:
rabbitmq-
description: | updated |
I'm almost certain that this isn't a rabbitmq bug, but is instead a juju 2.9 <-> 3.1 bug.
Firstly, the rabbitmq-charm isn't cross-model- relation 'safe', in that it doesn't encode the service name with the model, and thus two (say) nova-cloud- controllers in different models would *clash* and bad things would probably happen.
Secondly, I re-validated the 3.9/stable rabbitmq-server charm and checked it non-CMR in Juju 2.9, CMR in Juju 2.9, and I couldn't get it to even form a CMR between Juju 2.9 and Juju 3.1 in that although the offer was made and then received at the 3.1 model, no relation data was ever exchanged.
I've validated that a 3.1 rabbitmq non-CMR works, as well as a
I've validated several scenarios (as in the private-address isn't overwritten):
* Juju 2.9 - same model, no CMR.
* Juju 2.9 - cross-model.
* Juju 3.1 - same model, no CMR.
* Juju 3.1 - cross-model.
But I couldn't get the following to work:
* Juju 2.9 offer, Juju 3.1 claim: couldn't get it working.
And I've not tried this one:
* Juju 3.1 offer, Juju 2.9 claim: haven't tried it.
Thus, I'm not sure this is actually a rabbitmq-server charm bug.