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.

Sign up for GitHub

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

chore: update charm libraries #652

Merged
merged 1 commit into from
Dec 3, 2024
Merged

chore: update charm libraries #652

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 12 additions & 5 deletions lib/charms/observability_libs/v1/cert_handler.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@

LIBID = "b5cd5cd580f3428fa5f59a8876dcbe6a"
LIBAPI = 1
LIBPATCH = 14
LIBPATCH = 15

VAULT_SECRET_LABEL = "cert-handler-private-vault"

Expand Down Expand Up @@ -127,7 +127,7 @@ class _RelationVaultBackend(_VaultBackend):
_NEST_UNDER = "lib.charms.observability_libs.v1.cert_handler::vault"
# This key needs to be relation-unique. If someone ever creates multiple Vault(_RelationVaultBackend)
# instances backed by the same (peer) relation, they'll need to set different _NEST_UNDERs
# for each _RelationVaultBackend instance or they'll be fighting over it.
# for each _RelationVaultBackend instance, or they'll be fighting over it.

def __init__(self, charm: CharmBase, relation_name: str):
self.charm = charm
Expand Down Expand Up @@ -344,6 +344,13 @@ def __init__(
self.charm.on[self.certificates_relation_name].relation_joined, # pyright: ignore
self._on_certificates_relation_joined,
)
# The following observer is a workaround. The tls-certificates lib sometimes fails to emit the custom
# "certificate_available" event on relation changed. Not sure why this was happening. We certainly have some
# tech debt here to address, but this workaround proved to work.
self.framework.observe(
self.charm.on[self.certificates_relation_name].relation_changed, # pyright: ignore
self._on_certificate_available,
)
self.framework.observe(
self.certificates.on.certificate_available, # pyright: ignore
self._on_certificate_available,
Expand All @@ -366,7 +373,7 @@ def __init__(
)

if refresh_events:
logger.warn(
logger.warning(
"DEPRECATION WARNING. `refresh_events` is now deprecated. CertHandler will automatically refresh the CSR when necessary."
)

Expand Down Expand Up @@ -429,7 +436,7 @@ def enabled(self) -> bool:
See also the `available` property.
"""
# We need to check for units as a temporary workaround because of https://bugs.launchpad.net/juju/+bug/2024583
# This could in theory not work correctly on scale down to 0 but it is necessary for the moment.
# This could in theory not work correctly on scale down to 0, but it is necessary for the moment.

if not self.relation:
return False
Expand Down Expand Up @@ -636,7 +643,7 @@ def _on_all_certificates_invalidated(self, _: AllCertificatesInvalidatedEvent) -
# Note: assuming "limit: 1" in metadata
# The "certificates_relation_broken" event is converted to "all invalidated" custom
# event by the tls-certificates library. Per convention, we let the lib manage the
# relation and we do not observe "certificates_relation_broken" directly.
# relation, and we do not observe "certificates_relation_broken" directly.
self.vault.clear()
# We do not generate a CSR here because the relation is gone.
self.on.cert_changed.emit() # pyright: ignore
Expand Down
Loading