Currently when an admin executes "juju trust" a config-changed hook is fired, but there's no way to determine that it was the trust value that changed, or that the trust value changing was the cause of the event. It's not included in config-get results, sothere's no simple way to introspect the state of "trust" from the charm, without trying something that requires it and seeing if it fails with permission denied.
Here's a demonstration that the config-changed hook is executed, but nothing shows up when you run config-get
$ juju trust snappass-test --scope=cluster
$ juju show-status-log snappass-test/0
...
14 May 2021 17:26:26+12:00 juju-unit executing running config-changed hook
14 May 2021 17:26:26+12:00 juju-unit idle
$ juju run --unit snappass-test/0 "config-get"
{}
I believe "trust" is stored as application config, as it's shown on the client when you run "juju config" under that section, For example:
$ juju config snappass-test
application: snappass-test
application-config:
...
trust:
default: false
description: Does this application have access to trusted credentials
source: user
type: bool
value: true
charm: snappass-test
settings: {}
$ juju config snappass-test trust
true
So we need a way to introspect this from the charm. Adding a "--app" flag to config-get seems reasonable, so the charm would call "config-get --app" to get these values. (We could either return just app config if --app was specified, or somehow return all values -- but need to figure out how to namespace them if we do the latter.)
Jon Seager opened a related bug for the Python Operator Framework (https://github.com/canonical/operator/issues/532) that asks for this functionality to be exposed in Operator Framework. Once this work is done in Juju we should add a way to fetch it there. Possibly model.app_config would lazily call "config-get --app"?
WIP spec: https:/