Ceph Broker Conversation does not complete with CMR
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Ceph Monitor Charm |
Fix Released
|
Wishlist
|
Unassigned | ||
| Charm Helpers |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
With CMR (Cross Model Relation), Ceph Broker Conversation does not complete with:
"Ignoring legacy broker_rsp without unit key as remote service supports unit specific replies"
Because it assumes "broker-
How to reproduce:
1. deploy ceph-mon in default model
2. offer ceph-mon for CMR
$ juju offer ceph-mon:client
3. deploy cinder-backup for example in another model.
$ juju add-model another-model
$ juju deploy cinder
$ juju config cinder block-device=None
$ juju deploy cinder-backup
$ juju add-relation cinder cinder-backup
4. add CMR
$ juju add-relation admin/default.
[model log]
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
unit-cinder-
[relation data]
$ juju run -m another-model --unit cinder-backup/0 -- relation-get -r ceph:2 - ceph-mon/0
auth: cephx
broker-
"e4b59d93-
broker_rsp: '{"exit-code": 0, "request-id": "e4b59d93-
ceph-public-
egress-subnets: 10.0.8.155/32
ingress-address: 10.0.8.155
key: AQCE5kJbbD0SGBA
private-address: 10.0.8.155
$ juju run -m default --unit ceph-mon/0 -- relation-get -r client:7 - remote-
broker_req: '{"api-version": 1, "request-id": "e4b59d93-
"ops": [{"group": null, "name": "cinder-backup", "weight": null, "replicas": 3,
"pg_num": null, "group-namespace": null, "op": "create-pool"}]}'
egress-subnets: 10.0.8.131/32
ingress-address: 10.0.8.131
private-address: 10.0.8.131
| Changed in charm-ceph-mon: | |
| status: | New → Triaged |
| Changed in charm-helpers: | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
| Changed in charm-ceph-mon: | |
| importance: | Undecided → Wishlist |
| Cory Johns (johnsca) wrote | #1 |
| OpenStack Infra (hudson-openstack) wrote Fix merged to charm-ceph-mon (master) | #2 |
| Changed in charm-ceph-mon: | |
| status: | In Progress → Fix Committed |
| Changed in charm-ceph-mon: | |
| milestone: | none → 20.10 |
| Changed in charm-ceph-mon: | |
| status: | Fix Committed → Fix Released |
This also impacts the Kubernetes charms, and leads us to use the admin key for everything, rather than the client key, since we don't know (at least with CMR) what username the client key is associated with.
Perhaps it would be sufficient to echo back the service_name that was used over the relation in a new key. Then charmhelpers could be updated to look for that key, and if found, use it instead of local_unit() when calculating the broker_rsp key; and Kubernetes could also use it as the userID value.