Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remote unit data is inaccessible in relation-departed #1109

Open
tonyandrewmeyer opened this issue Jan 15, 2024 · 0 comments
Open

remote unit data is inaccessible in relation-departed #1109

tonyandrewmeyer opened this issue Jan 15, 2024 · 0 comments
Assignees
Labels
24.10 bug Something isn't working

Comments

@tonyandrewmeyer
Copy link
Contributor

tonyandrewmeyer commented Jan 15, 2024

The docs say:

A unit’s relation settings persist beyond its own departure from the relation
[...]
During a relation-departed hook, relation settings can still be read (with relation-get) [...] All units will still be able to see all other units

However, it's not possible (without using a private attribute) to access remote data from ops.

This pair of example charms demonstrate the issue:

  • 'provider-charm' puts some example data into the local unit relation databag on relation-joined and does nothing else.
  • 'require-charm' logs that data on relation-changed (just to show it's accessible normally) and attempts to log that data on relation-departed. However, that will fail, unless we get the data with manually creating a RelationDataContent object, which requires using model._backend.

To use the charms:

  1. charmcraft pack each charm, and juju deploy them into a model (I used k8s but I believe this will be the case for machine as well)
  2. juju integrate the two charms together
  3. Wait for everything to settle down (you'll see that the data is in the relation databag from the relation-changed debug-log output)
  4. Use juju remove-relation to remove the integration between the applications
  5. You should see departed: foo and departed (using private): foo in juju debug-log, but instead will see departed: COULD NOT GET IT. and departed (using private): foo.

The reason for this is that Relation.units is populated by running Juju's relation-list, which doesn't have the departing relation in the relation-departed event. Relation.data is a RelationData object, and the ._data attribute (which __getitem__ exposes) is populated with (a) data for the local unit, (b) data for the local app, and (c) data for each unit in the relation's .units. In (e.g.) relation-changed, this means that the remote unit's data will be there, but in relation-departed it will not.

Juju's relation-get will still provide access to the data, and this is meant to be available (according to the docs linked above and also the Juju team). However, the only method ops provides to use relation-get is via the RelationDataContent class (which needs the backend passed to instantiate an object) or RelationData (which needs the unit to be in relation-list as described above).

It seems like we should make this data available. It seems cleanest for it to be available in Relation.data like it would be outside of relation-departed - the departed unit is available in the environment and in the event object, so there would need to be a bit of work to get it into Relation.data without passing too much context around, but it's certainly feasible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
24.10 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants