Skip to content

tls: add sunbeam cluster refresh manual-tls-certificates-operator com…#715

Draft
hemanthnakkina wants to merge 1 commit into
canonical:mainfrom
hemanthnakkina:update-manifest
Draft

tls: add sunbeam cluster refresh manual-tls-certificates-operator com…#715
hemanthnakkina wants to merge 1 commit into
canonical:mainfrom
hemanthnakkina:update-manifest

Conversation

@hemanthnakkina
Copy link
Copy Markdown
Collaborator

…mand

  • Add MANUAL_CERT_AUTH_CHANNEL constant to versions.py and replace hardcoded "1/stable"/"latest/stable" strings in tls/ca.py, tls/common.py and tls/vault.py
  • Add manual-tls-certificates to INFRA_APPS so the generic LatestInChannel refresh skips it
  • Add ManualTLSCharmUpgradeStep (steps/manual_tls.py) which:
    • Skips if the app is not deployed
    • Skips if a revision is pinned in manifest and already matches the deployed revision
    • Skips if no revision is pinned and the deployed channel and revision already match the latest available on the manifest channel
    • Uses snapshot_workload_status to accept the pre-refresh workload status or active when waiting
    • Passes channel and revision from manifest to charm_refresh, falling back to MANUAL_CERT_AUTH_CHANNEL
    • Updates terraform tfvars after refresh (manifest takes precedence over override for charm keys)
  • Add sunbeam cluster refresh manual-tls-certificates-operator subcommand with optional -m/--manifest flag
  • Add unit tests covering all skip/run branches

@hemanthnakkina hemanthnakkina marked this pull request as draft March 16, 2026 10:29
@Raven-182
Copy link
Copy Markdown

LGTM overall. The only concern I have is allowing switching channels using the manifest. For example, I deployed manual-tls-certificates manually on 1/stable with ubuntu@24.04, but trying to upgrade it to latest/stable fails because latest/stable only supports ubuntu@22.04. This failure will be caught by the exception handling in this step, but should switching channels in this way be allowed at all?

@hemanthnakkina
Copy link
Copy Markdown
Collaborator Author

LGTM overall. The only concern I have is allowing switching channels using the manifest. For example, I deployed manual-tls-certificates manually on 1/stable with ubuntu@24.04, but trying to upgrade it to latest/stable fails because latest/stable only supports ubuntu@22.04. This failure will be caught by the exception handling in this step, but should switching channels in this way be allowed at all?

Thanks for the review!

In these specific commands for INFRA_APPS we should be supporting switching channels. I will try the other way round and see what happens i.e., switching from latest/stable to 1/stable

…mand

- Add MANUAL_TLS_CERTIFICATES_CHANNEL constant to versions.py and replace
  hardcoded "1/stable"/"latest/stable" strings in tls/ca.py,
  tls/common.py and tls/vault.py
- Add manual-tls-certificates to INFRA_APPS so the generic
  LatestInChannel refresh skips it
- Add ManualTLSCharmUpgradeStep (steps/manual_tls.py) using the shared
  check_charm_needs_refresh helper (charm_upgrade.py) which:
  - Skips if the app is not deployed
  - Skips if already at the manifest-pinned revision
  - Skips if already at the latest revision on the effective channel
  - Returns FAILED for invalid/downgrade channel in manifest
  - Passes --channel to charm_refresh only when the channel actually
    changes (avoids unintended track switches on patch upgrades)
  - Waits for active via wait_until_active (catches JujuWaitException
    in addition to TimeoutError)
  - Updates terraform tfvars after refresh
- Add `sunbeam cluster refresh manual-tls-certificates-operator`
  subcommand with optional -m/--manifest flag
- Add unit tests covering all skip/run branches
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants