feat: Smooth cross-track upgrades#305
Draft
MichaelThamm wants to merge 10 commits intomainfrom
Draft
Conversation
This was referenced Apr 24, 2026
This was referenced Apr 24, 2026
Contributor
Author
7e48e9f to
213b505
Compare
MichaelThamm
commented
Apr 25, 2026
|
|
||
| module "grafana" { | ||
| source = "git::https://github.com/canonical/grafana-k8s-operator//terraform" | ||
| source = "git::https://github.com/canonical/grafana-k8s-operator//terraform?ref=test/lifecycle-input" |
Contributor
Author
There was a problem hiding this comment.
Revert before merge
Contributor
Author
There was a problem hiding this comment.
Run terraform docs on the READMEs before merging
MichaelThamm
commented
Apr 25, 2026
MichaelThamm
commented
Apr 27, 2026
MichaelThamm
commented
Apr 27, 2026
MichaelThamm
commented
Apr 27, 2026
| } | ||
|
|
||
| resource "juju_integration" "grafana_ingress" { | ||
| count = var.ingress["grafana"] ? 1 : 0 |
Contributor
Author
There was a problem hiding this comment.
See if this works
Suggested change
| count = var.ingress["grafana"] ? 1 : 0 | |
| count = var.ingress.grafana ? 1 : 0 |
sed-i
approved these changes
Apr 27, 2026
sinapah
approved these changes
Apr 27, 2026
Abuelodelanada
approved these changes
Apr 27, 2026
MichaelThamm
commented
Apr 27, 2026
|
|
||
| module "cos" { | ||
| source = "git::https://github.com/canonical/observability-stack//terraform/cos?ref=track/2" | ||
| source = "git::https://github.com/canonical/observability-stack//terraform/cos?ref=test/lifecycle-input-track-2" |
Contributor
Author
There was a problem hiding this comment.
revert and other itest branches
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Blocked by:
Workaround for:
Blocks:
Relates to:
Issue
We want a smooth UX for users upgrading across tracks for our product modules: COS and COS Lite. Ideally, a user should be able to take their track/2 state and plan an upgrade to track/3.0 without any manual intervention.
Solution
juju_charmdatasource to provide the latest revisions for all charms in their respective tracks.lifecycle {replace_triggered_by = [...]}to replace the Grafana ingressjuju_integrationin the event that the interface changes.replace_triggers = [terraform_data.grafana_litestream_resource.id]to replace the Grafanajuju_applicationin the event that thelitestream-imageresource was removed.Important
I made a design decision to host all the upgrade logic in the product modules centralized in a
upgrades.tffile. This is done by featuring thereplace_triggersinput into the Grafana TF module. In the future, other charm modules which require juju_application replacements will need this feature as well. This design allows both the charm and product modules to have full control over when the application gets replaced vs. just the charm module having that control.To summarize, we will have this design:

instead of this one:

Warning
A cross-track upgrade that works today is not guaranteed to work tomorrow because the revisions are now refreshed in-track. Also, our users may be on any combination of revisions before they try to upgrade to track/3.0. This might be a good reason to have everyone
terraform applywith a tested set of revision pins prior to upgrading tracks.Checklist
tfatwice to itest to ensure that everything is applied prior to the juju-doctor probe. Otherwise, we should add the lifecycles to all resourcesContext
In the future charms will have unique tracks which the products needs to map to:
Testing Instructions
See this comment for details:
The general idea is to:
2/stabledev/edgeterraform init -upgrade; terraform applyDocumentation
Documentation will be addressed in:
Upgrade Notes
Since this will re-create the Grafana application, users will lose any custom configurations e.g., plugins that they have added to their Grafana. See the release notes for upgrading from track/2 to the following track/3.0