docs: document user-secret observer lifecycle and secret-changed semantics#2522
Conversation
| self.framework.observe(self.on.secret_changed, self._on_secret_changed) | ||
|
|
||
| def _on_config_changed(self, event: ops.ConfigChangedEvent): | ||
| secret_uri = self.config.get('my-secret-option') |
There was a problem hiding this comment.
This could use load_config but it seems like it would unnecessarily complicate the example.
Co-authored-by: Tony Meyer <tony.meyer@gmail.com>
The new section linked to manage-configuration via {external+ops:ref},
but the ops docs are this Sphinx project and there is no "ops" entry
in intersphinx_mapping, so the build failed under --fail-on-warning.
Use {ref} to match the convention in the sibling how-to files.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
dwilding
left a comment
dwilding
left a comment
There was a problem hiding this comment.
Nice updates, thanks! All comments are minor
|
|
||
| 1. Create the secret: `juju add-secret my-secret key=value` | ||
| 2. Grant it to the application: `juju grant-secret my-secret <app-name>` | ||
| 3. Set the configuration option to the secret URI: `juju config <app-name> <secret-option>=<secret-uri>` |
There was a problem hiding this comment.
Where does the secret URI come from?
There was a problem hiding this comment.
The add-secret output. Should the (1) say something like "Create the secret and record the secret URI in the output: juju...? Or (3) say something like:
| 3. Set the configuration option to the secret URI: `juju config <app-name> <secret-option>=<secret-uri>` | |
| 3. Set the configuration option to the secret URI that `secret-add` output: `juju config <app-name> <secret-option>=<secret-uri>` |
Or a different approach?
There was a problem hiding this comment.
I prefer adjusting (3), but with "returned" instead of "output"
Co-authored-by: Dave Wilding <tech@dpw.me>
Apply suggestions from PR canonical#2522 review: - Add a meta description for the page. - Reorder the Prerequisites section so the charm-side configuration option declaration comes before the steps the Juju user must take. - Link the See more pointer at the charmcraft config key reference instead of the Charmcraft Manage secrets page.
Use plain text for "See first / See more / See also" pointers, convert
the "See first" pointer into a bulleted list, and wrap the
non-pointer callouts ("Added in Juju 3.0.2", "By its nature ...") as
{note} admonitions. These lines aren't actually quotes, so the
leading > was misleading.
|
I figured since I'm doing a "see also" link I should move this page away from the block quote style. @dwilding would you mind doing a brief re-review to validate those bits? |
dwilding
left a comment
dwilding
left a comment
There was a problem hiding this comment.
I figured since I'm doing a "see also" link I should move this page away from the block quote style. @dwilding would you mind doing a brief re-review to validate those bits?
Looks good, thanks a lot! Just a couple of extra suggestions.
tromai
left a comment
tromai
left a comment
There was a problem hiding this comment.
Thank you for the docs update.
I read through the whole manage-secrets page and the added section looks good to me.
Co-authored-by: Dave Wilding <tech@dpw.me>
Co-authored-by: Dave Wilding <tech@dpw.me>
3 participants
This PR expands our secrets how-to so that it more clearly explains the differences between managing charm-owned secrets and user secrets.
A new section is added that explains the user secrets path. This is simpler than a charm-owned secret, since there's only one event to handle: config-changed.
Preview
See juju/juju#18892 for more context.