cli: Terraform migrations on upgrade #1685

msanft · 2023-04-26T07:39:17Z

Proposed change(s)

Implement migration of cloud resources on Constellation version upgrades. (e.g. Constellation 2.6.0 doesn't create an MAA, while 2.7.0 does optionally and 2.8.0 always creates one)
- In that case, a user with a cluster without an MAA (2.6.0/2.7.0) downloads the 2.8.0 CLI and runs the upgrade apply command to have a MAA added to his cloud resources.
How the migration works:
- The old Terraform directory constellation-terraform is backed up into constellation-upgrade/constellation-upgrade-terraform-backup. If the user wants to rollback to the pre-upgrade state, he can do it there
- Constellation copies the old Terraform state from the constellation-terraform dir into the constellation-upgrade/constellation-upgrade-terraform dir.
- Constellation populates the constellation-upgrade/constellation-upgrade-terraform dir with the new Terraform script files (embedded in the CLI)
- Constellation performs a terraform plan on selected targets (as of now, only on the MAA on Azure)
- The resulting diff is shown to the user who can confirm it or abort the upgrade.
- If the user confirms the diff (resources to be crated / changed / etc.), the new script is applied on the selected target (in simpler terms; the output confirmed by the user gets created)
- The old Terraform directory constellation-terraform is replaced with the new constellation-upgrade/constellation-upgrade-terraform. The output of the migrated resources is written into terraform-migration-output.json (e.g. the attestation URL of the MAA provider)

Additional info

TODO: Add e2e test run

Checklist

Update docs
Add labels (e.g., for changelog category)
Link to Milestone

netlify · 2023-04-26T07:39:34Z

✅ Deploy Preview for constellation-docs canceled.

Name	Link
🔨 Latest commit	`02fd7bf`
🔍 Latest deploy log	https://app.netlify.com/sites/constellation-docs/deploys/646b4a9ac909fa000856ec6e

e2e/internal/upgrade/upgrade_test.go

internal/constants/constants.go

cli/internal/kubernetes/upgrade.go

cli/internal/cloudcmd/create.go

cli/internal/cmd/upgradeapply.go

cli/internal/kubernetes/upgrade.go

cli/internal/terraform/terraform/azure/main.tf

derpsteb · 2023-05-09T06:30:52Z

re "design descision": I would expect constellation terminate to delete all my resources. I don't see a reason why we would not replace the old state. Which reasons are there?

re "Constellation performs a terraform plan on selected targets (as of now, only on the MAA on Azure)": could you point me to the code that restricts the plan to any specific resources? while reading the changes it seemed to me like a general plan would happen on all resources.

msanft · 2023-05-11T09:27:30Z

re "selected targets"

Planning and applying the configuration uses the targets flag which specifies resources to plan / apply the configuration for.
The specific targets get set here.

msanft · 2023-05-11T09:30:54Z

re "design decision"

The reason I would see is, that if an upgrade goes wrong, the user should be able to rollback to the old resource state manually. Therefore we should at least keep the old state somewhere in the upgrade folder. I will prepare something to put the current state into a backup folder and move the upgraded state into the constellation-terraform folder

internal/constants/constants.go

cli/internal/cmd/upgradeapply.go

cli/internal/kubernetes/upgrade.go

Co-authored-by: Otto Bittner <cobittner@posteo.net>

cli/internal/upgrade/terraform.go

cli/internal/cmd/upgradeapply.go

derpsteb

Just tested it again on AWS and Azure. Looks great now :)

msanft added the feature This introduces new functionality label May 4, 2023

msanft added this to the v2.8.0 milestone May 4, 2023

msanft requested a review from derpsteb May 4, 2023 09:06

msanft marked this pull request as ready for review May 4, 2023 09:06

msanft requested review from katexochen and daniel-weisse as code owners May 4, 2023 09:06

katexochen removed their request for review May 4, 2023 09:09