Skip to content

Conversation

@paigecalvert
Copy link
Contributor

@paigecalvert paigecalvert commented Feb 19, 2025

@replicated-ci replicated-ci added type::docs Improvements or additions to documentation type::feature labels Feb 19, 2025
@netlify
Copy link

netlify bot commented Feb 19, 2025

Deploy Preview for replicated-docs ready!

Name Link
🔨 Latest commit 871d3a5
🔍 Latest deploy log https://app.netlify.com/sites/replicated-docs/deploys/67c7222de894df0008d3d512
😎 Deploy Preview https://deploy-preview-3066--replicated-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@netlify
Copy link

netlify bot commented Feb 19, 2025

Deploy Preview for replicated-docs-upgrade ready!

Name Link
🔨 Latest commit 871d3a5
🔍 Latest deploy log https://app.netlify.com/sites/replicated-docs-upgrade/deploys/67c7222dc4120600086a97f8
😎 Deploy Preview https://deploy-preview-3066--replicated-docs-upgrade.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@paigecalvert paigecalvert marked this pull request as ready for review February 20, 2025 00:34
@paigecalvert paigecalvert requested a review from a team as a code owner February 20, 2025 00:34
This flag allows Helm to take ownership of existing resources that were installed without Helm, like resources deployed with HelmChart v1beta1 and `useHelmInstall: false`.

To migrate an existing installation from `kots.io/v1beta1` with `useHelmInstall: false` to `kots.io/v1beta2`, reach out to your Replicated account representative in Slack or over email.
For information about how to migrate an existing installation to KOTS HelmChart `v1beta2`, see [Migrating Existing Installations to HelmChart v2](/vendor/helm-v2-migrate).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ added link to the migration topic

Existing KOTS installations can be migrated to use the KOTS HelmChart v2 method, without having to reinstall the application.

To migrate an existing installation from `kots.io/v1beta1` with `useHelmInstall: false` to `kots.io/v1beta2`, reach out to your Replicated account representative in Slack or over email.
There are different steps for migrating to HelmChart v2 depending on the application deployment method used previously. For more information, see [Migrating Existing Installations to HelmChart v2](helm-v2-migrate).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ Replaced "reach out to your rep" with a link to the migration steps


:::note
Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades** because customers must upgrade to this release first before they can upgrade to the release that migrates their installation to HelmChart v2.
:::
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ recommend using required releases

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think the second one needs to be required, unless they're going to remove the --take-ownership flag in a later release. it would need to be required if only this version has --take-ownership applied. which could be a good idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The workflow I was trying to capture was testing the first (required) release, then promoting that same release to a customer-facing channel and again marking it as required.

But that said, the second release does have the --take-ownership flag...so it sounds like maybe it could be helpful to actually mark both the first and second releases are required?


### Where can I find additional help migrating existing installations to HelmChart v2?

For additional support migrating existing installations to HelmChart v2, Replicated recommends that you post your question in the [Replicated Community](https://community.replicated.com/) site. You can also reach out to your Replicated account representative.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ post on community or reach out to your rep if you need help


1. Create a new release containing your application files:

1. Add the `kots.io/keep` annotation to any resources that were previously installed with `kubectl apply`, including resources defined in Kubernetes manifests or in your Helm `templates`. The `kots.io/keep` annotation prevents KOTS from uninstalling resources that were previously installed without Helm when upgrading using the HelmChart v2 method.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Customers might not realize that v1 false uses kubectl apply. from their pov, they think it's a helm chart. so i wonder if we should make that clearer here. i might read this and say, well i had a helm chart, so no resources were applied with kubectl. but in reality, everything in the chart was kubectl applied.


1. Add the `kots.io/keep` annotation to any resources that were previously installed with `kubectl apply`, including resources defined in Kubernetes manifests or in your Helm `templates`. The `kots.io/keep` annotation prevents KOTS from uninstalling resources that were previously installed without Helm when upgrading using the HelmChart v2 method.

1. In the `helmUpgradeFlags` field of the Embedded Cluster Config, add the `--take-ownership` flag, as shown below:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not EC Config, helm chart v2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops good catch


1. In a development environment, install the release to test that you can upgrade to the new release successfully.

1. When you are done testing, promote the release to one or more of your customer-facing channels.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would you want to remove the keep annotation in a subsequent release though? I'm not sure if it matters or if @nvanthao tested it.


:::note
Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades** because customers must upgrade to this release first before they can upgrade to the release that migrates their installation to HelmChart v2.
:::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think the second one needs to be required, unless they're going to remove the --take-ownership flag in a later release. it would need to be required if only this version has --take-ownership applied. which could be a good idea.


### Which migration scenarios require the `kots.io/keep` annotation?

When applied to a resource in a release, the `kots.io/keep` annotation prevents the given resource from being uninstalled. The `kots.io/keep` annotation can be used to prevent KOTS from deleting resources that were either adopted into Helm charts, or that were previously deployed without Helm.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nvanthao does this annotation work if you put it on a resource in a Helm chart, or does it only work for manifests in a release?


1. Instruct customers to migrate by first upgrading to the release where the `kots.io.keep` annotation is applied to your resources, then upgrading to the release with HelmChart v2.

1. In subsequent releases, remove the `helmUpgradeFlags` field (including the `--take-ownership` flag) from the HelmChart custom resource. This flag is only required during one upgrade to allow Helm to take ownership of your application resources.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ added step to remove the flag for later releases since it's not needed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just say to remove the take ownership flag, since they could be specifying other helm upgrade flags that they want to keep

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm thinking of this correctly, they should also remove the keep annotation from the templates. Since this is the same chart, the annotation would be there, and we don't want that in the future (though I don't think KOTS will actually do anything about it anyway since it's in a Helm chart). But for cleanup purposes, that might be best.

@paigecalvert paigecalvert requested a review from ajp-io February 27, 2025 21:59

1. Instruct customers to migrate by first upgrading to the release where the `kots.io.keep` annotation is applied to your resources, then upgrading to the release with HelmChart v2.

1. In subsequent releases, remove the `helmUpgradeFlags` field (including the `--take-ownership` flag) from the HelmChart custom resource. This flag is only required during one upgrade to allow Helm to take ownership of your application resources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just say to remove the take ownership flag, since they could be specifying other helm upgrade flags that they want to keep


1. Instruct customers to migrate by first upgrading to the release where the `kots.io.keep` annotation is applied to your resources, then upgrading to the release with HelmChart v2.

1. In subsequent releases, remove the `helmUpgradeFlags` field (including the `--take-ownership` flag) from the HelmChart custom resource. This flag is only required during one upgrade to allow Helm to take ownership of your application resources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm thinking of this correctly, they should also remove the keep annotation from the templates. Since this is the same chart, the annotation would be there, and we don't want that in the future (though I don't think KOTS will actually do anything about it anyway since it's in a Helm chart). But for cleanup purposes, that might be best.

@paigecalvert paigecalvert merged commit 77a4219 into main Mar 4, 2025
5 checks passed
@paigecalvert paigecalvert deleted the 120396 branch March 4, 2025 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type::docs Improvements or additions to documentation type::feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants