non-leader unable to retrieve local application relation data

[Stuart Bishop]

Attempting to run 'relation-get -r 2 - myapp --app=True' works on the lead myapp unit, but fails on the non-leaders. The error is 'ERROR permission denied'.

My main use case is a relation API, where the lead unit is setting application relation data. For backwards compatibility with older versions of server at the remote end of the relation, non-lead units need to mirror the application relation data to their standard relation data.

Another use case is upgrade-charm with the operator framework, upgrading standard relation data to application relation data:

def on_upgrade_charm(self, event: ops.charm.UpgradeCharmEvent) -> None:
    # Migrate leader's unit relation data to application relation data if necessary.
    # This is for upgrading from pre-operator-framework charms.
    for rel in self.framework.model.relations[self.relation_name]:
        ldata = rel.data[self.model.unit]
        adata = rel.data[self.model.unit.app]
        for k in ['database', 'roles', 'extensions']:
            if k in ldata and k not in adata:
                if self.model.unit.is_leader():
                    adata[k] = ldata[k]
                else:
                    # Defer, in case we are promoted to leader and need to perform the upgrade.
                    event.defer()
                    return

Confirmed with 2.7.5+2.7-3a6aa80, so I believe this is different to Bug #1865229

[Richard Harding (rharding)]

My understanding is that the idea is that if leadership data is intended to be specific to between two applications. If peers need information it would be shared over peer relation data vs exposing the app level data to every unit. In this way not all changes to the application level data need to trigger change events to every peer/unit that exists. The change of app level data only goes between leaders. The leader can then optionally propagate a change if that change is specific to the peers. However, there's a filter in play.

[Richard Harding (rharding)]

Marking as won't fix for the moment as I believe this is very much intentional but let me know if that's unclear or there's more debate to the design to be had.

[Tim McNamara (tim-clicks)]

Let's push this discussion to the #charming category of the Discourse: https://discourse.juju.is/c/charming. I remember hearing rationale for not allowing leaders to read application-level data, but I don't recall what that rationale is.

[Stuart Bishop (stub)]

On Wed, 1 Apr 2020 at 03:50, Richard Harding <email address hidden>
wrote:

> My understanding is that the idea is that if leadership data is intended
> to be specific to between two applications. If peers need information it
> would be shared over peer relation data vs exposing the app level data
> to every unit. In this way not all changes to the application level data
> need to trigger change events to every peer/unit that exists. The change
> of app level data only goes between leaders. The leader can then
> optionally propagate a change if that change is specific to the peers.
> However, there's a filter in play.

Using a peer relation does not seem suitable when writing relation
implementations, as they have no way to define one. They would either need
the charmer using the relation implementation to define an extra peer
relation, or hijack the charms existing peer relation (charmer is required
to ensure it exists too I guess).