The latest vintage and the first CAPI release - versions of apps and components

[nprokopic]

Towards #3057

User Story

As a Giant Swarm engineer, I want to know which are the versions of apps and components in the latest vintage release and in the first CAPI release, so that I can know what app and component versions my team has to test and support for vintage to CAPA migration.

Acceptance Criteria

• Given my team owns an app which is a part of the vintage and/or CAPI release, when my team plans the development and the support of that app, then we have to know which versions of the app we have to support and maintain for the vintage to CAPA migration.
• Given my team owns an app which is a part of the vintage and/or CAPI release, when my team releases a new patch/minor/major version of the app (patch to the version in the latest vintage release), then we have to know without any doubt if we can and if we have to create a new latest vintage release and if we can and if we have to create a new first CAPI release and if we have to re-test the migration from the new vintage release to the new first CAPI release.

Dependencies

• TBA

Tasks

• Define which app and component (e.g. Kubernetes, OS) versions we have in the latest vintage release.
• Define which app and component (e.g. Kubernetes, OS) versions we have in the first CAPI release.
• Define if we can create new vintage patch and minor releases (newer than v20.0.0), and if we should, then which types of changes we want to deliver in newer releases and which new versions of apps and components (e.g. only patches, or patches and minors) should be included in those new releases.
• If we will be creating new vintage releases, then define if we will have to create also new CAPI releases with the same changes we made in the newer vintage releases. E.g. if new vintage release delivers a new patch version of app Foo, define if we have to create a new CAPI release that delivers that new patch version of the app Foo.

[nprokopic]

Suggestion

• Versions of all apps and components have to be the same in the latest vintage release and in the first CAPA release.
• If we create a new latest vintage release where we include a new patch version of an app Foo, we also have to create a new first CAPA release where we include that new patch version of the app Foo.
• We don't create new releases for new minor and major versions of apps and components.

Scenario: we release a new patch version of an app

Given we have these vintage (AWS) and CAPA releases:

• AWS release v20.0.0
  • coredns v1.21.0
• CAPA release v25.0.0 (example number for the sake of example scenario here, not a decided number)
  • coredns v1.21.0

where we support migration from AWS v20.0.0 to CAPA v25.0.0 release

When we release new patch version coredns v1.21.1

Then we have to create these new vintage (AWS) and CAPI (CAPA) releases:

• AWS release v20.0.1
  • coredns v1.21.1
• CAPA release v25.0.1
  • coredns v1.21.1

And the following upgrade and migration paths are then supported:

• For vintage clusters that do not use the latest vintage release version:
  • Upgrade from the latest AWS v19.x.y to AWS v20.0.1 release.
  • Upgrade from v20.0.0 to v20.0.1 release.
• For CAPI clusters that have been already migrated to CAPA release v25.0.0:
  • Upgrade from v25.0.0 to v25.0.1 release.
• For vintage clusters that use the latest vintage release version v20.0.1:
  • Migration from AWS v20.0.1 to CAPA v25.0.1 release.

Challenges

• The latest vintage release v20.0.0 and the latest versions of cluster-aws and default-apps-aws (we still don't have a proper release) currently have different versions of some apps.
  • e.g. AWS v20.0.0 has cert-exporter v2.9.0, and the latest default-apps-aws v0.49.0 has cert-exporter v2.8.5
  • e.g. AWS v20.0.0 has cert-exporter v2.9.0, and the latest default-apps-aws v0.49.0 has cert-exporter v2.8.5
  • If CAPA is using an older version, then we don't have an issue, we will upgrade it easily.
  • If vintage is using an older version, then we should check if this version difference can cause issues in migration, and (at some point) create a new vintage release that includes the same version of the app as the first CAPA release.
• New patch versions of apps will require both new vintage and CAPA releases, which means:
  • Testing those new releases (less of an issue on CAPA).
  • Testing new migration path from the new latest vintage release to the new first CAPA release.
• We will need a simple and scalable process for creating new releases.

[nprokopic]

This story does not cover what to do when we release a new minor or major version of an app. I will try to cover that in another story.

[nprokopic]

Suggestion

• Versions of all apps and components have to be the same in the latest vintage release and in the first CAPA release.
• If we create a new latest vintage release where we include a new patch version of an app Foo, we also have to create a new first CAPA release where we include that new patch version of the app Foo.

If we want to do this (IMO we really have to, otherwise vintage to CAPA migration is too unpredictable and not reliable, as it can break with any new app version), we should decide what are the desired app versions for the last vintage release and first CAPA release:

• Compare the app versions in the current latest vintage AWS release to app versions in the latest CAPA (ATM cluster-aws and default-apps-aws, in a few days cluster-aws and cluster chart).
• For every app we pick the newer version of the above two as the desired app version.
• We check with teams that own default apps if they need to release a newer patch or even a minor and if they need that very soon (e.g. this or next week). If the answer is yes, then this is our desired app version.

cc @yulianedyalkova @alex-dabija

cc @giantswarm/team-turtles @giantswarm/team-phoenix for general awareness about the topic here

[alex-dabija]

I think we can close this issue because v25 is released and we already migrated a cluster.

[Gacko]

Well, this on its own wouldn't cover the acceptance criteria. But I think we have everything in the releases, right @nprokopic?

[nprokopic]

This has been a moving target and it has already changed few times.

Now when I take a look at the above tasks, which are just questions for which we should have answers, I think we mostly have the answers.

Define which app and component (e.g. Kubernetes, OS) versions we have in the latest vintage release.

• Kubernetes version 1.25.x
• Flatcar version 3815.2.x
• When it comes to app versions, we are updating those only to fix bugs.

Define which app and component (e.g. Kubernetes, OS) versions we have in the first CAPI release.

The latest vintage and the first CAPI release should always be in sync as much as possible. Keeping app versions identical has shown to be not really possible, at least until now, as we had more than few cases where some app needed a newer version in v25 compared to v20.

Define if we can create new vintage patch and minor releases (newer than v20.0.0), and if we should, then which types of changes we want to deliver in newer releases and which new versions of apps and components (e.g. only patches, or patches and minors) should be included in those new releases.

As written above, we are updating vintage v20 release only to fix bugs.

If we will be creating new vintage releases, then define if we will have to create also new CAPI releases with the same changes we made in the newer vintage releases. E.g. if new vintage release delivers a new patch version of app Foo, define if we have to create a new CAPI release that delivers that new patch version of the app Foo.

App and component versions that are released in vintage as a v20 patch/minor release, should also be released in CAPI as a v25 release.

---

I think we can verify some of the above in the releases repo CI (at least to some extent), by checking app and component versions across different releases. Will create follow-up issues for Turtles, as we have already talked about release tests in the releases repo.