-
Notifications
You must be signed in to change notification settings - Fork 9
feat: Cross-track upgrades #174
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.
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
base: main
Are you sure you want to change the base?
Changes from all commits
aa244a2
6a5e192
d8b0fbd
0634ec8
2c634d1
424447a
b3b6492
91dcf5f
188e4f5
97f585a
440dbee
f4ffc38
5c7bf3a
055a627
42999c2
f2b3517
3f6cffc
7078c6e
2170e02
61f716f
1d27584
dba3cef
51dd4b7
db994ce
c7cfe08
b76242e
911c30b
42ac9a5
0187773
8903f5b
fa6561d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,111 @@ | ||
| # Refresh COS to a new channel | ||
|
|
||
| In this example, you will learn how to deploy COS Lite and refresh from channel `2/stable` to `2/edge`. To do this, we can deploy COS Lite via Terraform in the same way as [in the tutorial](https://documentation.ubuntu.com/observability/track-2/tutorial/installation/cos-lite-microk8s-sandbox). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Assuming this gets refactored into a tutorial, the language/framing should change so it's not like "In this example, you'll learn...". How-to guides aren't really "learning" experiences, it's more just like "here's the steps you need to do XYZ". Example: Charmed Kafka: How to upgrade |
||
|
|
||
| ## Prerequisites | ||
|
|
||
| This tutorial assumes that you already: | ||
|
|
||
| - Know how to deploy {ref}`COS Lite with Terraform <deploy-cos-ref>` | ||
|
|
||
| ## Introduction | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar to a comment I made above, this section can be less narrative if being refactored into a how-to guide (btw I'm happy to meet and discuss my comments with you if you want!) |
||
|
|
||
| Imagine you have COS Lite (or COS) deployed on a specific channel like `2/stable` and want to | ||
| refresh to a different channel (or track) e.g., `2/edge`. To do so, an admin would have to manually | ||
| `juju refresh` each COS charm and address any refresh errors. Alternatively, they can determine the | ||
| correct charm `channel` and `revision`(s), update the Terraform module, and apply. | ||
|
|
||
| This is simplified within COS (and COS Lite) by mimicking the `juju refresh` behavior on a product | ||
| level, allowing the juju admin to specify a list of charms to refresh within the specified | ||
| `track/channel`. The rest is handled by Terraform. | ||
|
|
||
| ## Update the COS Lite Terraform module | ||
|
|
||
| Once deployed, we can determine which charms to refresh with the `charms_to_refresh` input variable, detailed in the [README](https://github.com/canonical/observability-stack/tree/main/terraform/cos-lite). This defaults to: all charms owned by the `observability-team`. | ||
|
|
||
| ```{note} | ||
| This tutorial assumed you have deployed COS Lite from a root module located at `./main.tf`. | ||
| ``` | ||
|
|
||
| Then, replace `2/stable` with `2/edge` in your `cos-lite` module within the existing `./main.tf` file: | ||
|
|
||
| ```{literalinclude} /tutorial/installation/cos-lite-microk8s-sandbox.tf | ||
| --- | ||
| language: hcl | ||
| start-after: "# before-cos" | ||
| --- | ||
| ``` | ||
|
|
||
| ```{note} | ||
| The `base` input variable for the `cos-lite` module is important if the `track/channel` deploys charms to a different base than the default, detailed in the [README](https://github.com/canonical/observability-stack/tree/main/terraform/cos-lite). | ||
| ``` | ||
|
|
||
| Finally, add the provider definitions into the same `./main.tf` file: | ||
|
|
||
| ```hcl | ||
| terraform { | ||
| required_providers { | ||
| juju = { | ||
| source = "juju/juju" | ||
| version = "~> 1.0" | ||
| } | ||
| http = { | ||
| source = "hashicorp/http" | ||
| version = "~> 3.0" | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| At this point, you will have one `main.tf` file ready for deployment. Now you can plan these changes with: | ||
|
|
||
| ```shell | ||
| terraform plan | ||
| ``` | ||
|
|
||
| and Terraform plans to update each charm to the latest revision in the `2/edge` channel: | ||
|
|
||
| ```shell | ||
| Terraform used the selected providers to generate the following | ||
| execution plan. Resource actions are indicated with the following | ||
| symbols: | ||
| + create | ||
| ~ update in-place | ||
|
|
||
| Terraform will perform the following actions: | ||
|
|
||
| # module.cos.module.alertmanager.juju_application.alertmanager will be updated in-place | ||
| ~ resource "juju_application" "alertmanager" { | ||
|
|
||
| # snip ... | ||
|
|
||
| ~ charm { | ||
| ~ channel = "2/stable" -> "2/edge" | ||
| name = "alertmanager-k8s" | ||
| ~ revision = 191 -> 192 | ||
| # (1 unchanged attribute hidden) | ||
| } | ||
|
|
||
| # snip ... | ||
|
|
||
| Plan: 0 to add, 5 to change, 0 to destroy. | ||
| ``` | ||
MichaelThamm marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| and finally apply the changes with: | ||
|
|
||
| ```shell | ||
| terraform apply | ||
| ``` | ||
|
|
||
| At this point, you will have successfully upgraded COS Lite from `2/stable` to `2/edge`! | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The steps overall seem fine and pretty straightforward. I can provide some better feedback once it gets refactored into a how-to |
||
|
|
||
| ## Refresh information | ||
|
|
||
| This tutorial only considers upgrading COS Lite. However, the `charmhub` module is product-agnostic | ||
| and can be used to refresh charms, and other products e.g., COS. | ||
|
|
||
| You can consult the follow release documentation for refresh compatibility: | ||
|
|
||
| - [how-to cross-track upgrade](/how-to/upgrade/) | ||
| - [release policy](/reference/release-policy/) | ||
| - [release notes](/reference/release-notes/) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| # -------------- Upgrade logic -------------- | ||
|
|
||
| ## -------- grafana.revision >= 174 ---------- | ||
| # the ingress endpoint changes from traefik_route to ingress_per_app so we need a lifecycle to | ||
| # trigger integration replacement, otherwise the upgrade will fail | ||
| data "juju_charm" "grafana_info" { | ||
| charm = "grafana-k8s" | ||
| channel = var.channel | ||
| base = var.base | ||
| } | ||
|
|
||
| resource "terraform_data" "grafana_ingress_interface" { | ||
| input = data.juju_charm.grafana_info.requires["ingress"] | ||
| } | ||
|
|
||
| # -------------- End upgrade logic -------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Iirc we haven't started using these our docs yet.
Remind me - it's an anchor or cross-sphinx ref?
I think juju had this and it turned out to be brittle and difficult to maintain, but maybe I'm missing something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an anchor, but it can also be used as a cross-sphinx/project ref for projects that have that enabled.
You haven't started using them in the COS docs yet, but it is the standard approach to cross-linking for sphinx docs projects, so at some point, you should change your links to use these refs. Juju uses them in their docs, but I don't know what conversations happened around it
Using ref targets/anchors is nicer because otherwise anytime you change the filename/path, it'll break any of those links in your docs.
IMO, it could go either way in this PR (add it or don't add it), but the future goal should be that all docs have a ref target, and you use those for linking instead of file path. (Copilot should be able to handle it well when you do make this initiative)