App upgrade uses wrong repository when same name chart is available in multiple repos

[abhi1693]

Rancher Server Setup

• Rancher version: 2.6.0
• Installation option (Docker install/Helm Chart): Helm Chart
  • If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1
• Proxy/Cert Details: No proxy, Cloudflare certificate

Information about the Cluster

• Kubernetes version: v1.20.4
• Cluster Type (Local/Downstream): Downstream
  • If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider): vSphere

Describe the bug

I deployed minio today using the UI and I wanted to change the configuration, and the app started giving undefined annotations errors. I then realised from the developer options network tab that the UI is trying to fetch the chart from the wrong repo. The version that was deployed was not available in the other repo and so now I cannot upgrade the app.

To Reproduce

1. Add https://charts.bitnami.com/bitnami and https://helm.min.io/ to the chart repos
2. Using the chart in the minio repo, deploy the minion app with default settings
3. Try to upgrade, the UI will throw errors in YAML even if no changes are made

Result
The UI does not let me upgrade the app

Expected Result

The chart should use the repo via which it was deployed instead of using the first repo it finds itself in

Screenshots

Additional context

[abhi1693]

This issue exists with v2.5.10 as well using Cluster Explorer

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

It's still relevant

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

It's still relevant

[abhi1693]

The issue exists in v2.5.11 as well

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

Still relevant

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

Still relevant

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

Still relevant

[ikogan]

Still very relevant. This includes both helm charts that are local (not installed from any repository) as well as remote. It's now impossible to upgrade several apps in my clusters as they are present in more than one helm repo.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

Relevant

[ikogan]

Very relevant

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

Relevant even after 2 years

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[ikogan]

Relevant. I'm not sure exactly why some helm charts show up and others don't. A way to simply ignore them would be nice.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

@khushboo-rancher sorry to tag you but could this be looked at because after 2+ years, it's still an issue even in the latest versions.

[ikogan]

Yup, still relevant. Thanks @abhi1693!

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[abhi1693]

@khushboo-rancher Sorry to tag you, but can this be fixed? Been waiting for the team to see this for 2 years now.

@rancher-max @anupama2501 @richard-cox @nicholasSUSE @slickwarren @jiaqiluo

[richard-cox]

@abhi1693 i've transferred the issue to the repo responsible for UI.

Would you be able to expand on UI will throw errors in YAML? what is the error and where is it?

We have the ability at the moment to manually select the repo and chart if the chart for the app cannot be found. For a quick fix i think we should ..

• Make it clearer which repo, chart and version will be installed when the user clicks update on an existing app
• Allow the user to override / change the repo, chart and version which the UI finds
  This would be a nice 'catch all' scenario which covers other issues.

An expanded solution would be to record the helm repo url and chart name as an annotation on the helm app resource. The UI would then pick that by default when going to the update wizard.

[richard-cox]

Linking an issue where we incorrectly connect an existing app with a chart repo - #9613