You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should add Ops support for Pebble identity-related APIs: add, update, replace, and remove.
Design decisions:
Function names: probably Pebble and Container methods matching those on the Go client: get_identities, add_identities, replace_identities, remove_identities.
Or do we just want to add get_identities and replace_identities for now, since replacing is idempotent (which is what we want for charms) and also allows removal?
Should the argument be Mapping[str, pebble.Identity], strongly typed dataclasses matching the Go client.Identity type? In which case we'll need to add new types if we add new identity types, but that's probably okay (happens very slowly).
Typical call might look like this:
hashed=subprocess.run(['openssl', 'passwd', '-6'], capture_output=True, check=True).stdoutmodel.add_secret(hashed_password) # pseudo-code (but store it somewhere)container.replace_identities({
"web": pebble.Identity(access=pebble.MetricsAccess, basic=pebble.BasicIdentity(password=hashed)),
})
For documenting the above, generated API reference docs is probably fine. We should also write a doc for how to use them (with /v1/metrics) in a charm -- I'll open a separate issue for that.
The text was updated successfully, but these errors were encountered:
We should add Ops support for Pebble identity-related APIs: add, update, replace, and remove.
Design decisions:
Pebble
andContainer
methods matching those on the Go client:get_identities
,add_identities
,replace_identities
,remove_identities
.get_identities
andreplace_identities
for now, since replacing is idempotent (which is what we want for charms) and also allows removal?Mapping[str, pebble.Identity]
, strongly typed dataclasses matching the Go client.Identity type? In which case we'll need to add new types if we add new identity types, but that's probably okay (happens very slowly).Typical call might look like this:
For documenting the above, generated API reference docs is probably fine. We should also write a doc for how to use them (with /v1/metrics) in a charm -- I'll open a separate issue for that.
The text was updated successfully, but these errors were encountered: