Helm chart version in HCP depending on k8s version of workload cluster about cluster-api-addon-provider-helm HOT 10 CLOSED

@nikParasyr - I proactively added this as a discussion topic for the Cluster API meeting agenda next week 3/29. Hopefully we will see you there.

from cluster-api-addon-provider-helm.

This is something I discussed with @fabriziopandini and @jackfrancis in the initial design, and we're planning on looking into it as part of an additional iteration of the prototype. I found that some Helm charts like cloud-provider-azure already have existing logic for matching the chart version with the K8s version, so in that case some charts would likely work out of the box.

I'm just brainstorming, but I wonder if we can add an additional field like versionMap which could look something like this. The idea would be that if a regex in the map matches the K8s version, we install/upgrade to that version and if isn't in the map, we just default to the version specified in the version field. What do you think about this?

versionMap:
  1.24.*: 2.1.3.0
  1.25.*: 2.14.0

from cluster-api-addon-provider-helm.

I found that some Helm charts like cloud-provider-azure already have existing logic for matching the chart version with the K8s version

This is interesting. Although i'd say we can't expect all upstream helm charts to have such logic and adding that logic could be a lot of work for users.

I'm just brainstorming, but I wonder if we can add an additional field like versionMap which could look something like this. The idea would be that if a regex in the map matches the K8s version, we install/upgrade to that version and if isn't in the map, we just default to the version specified in the version field. What do you think about this?

I think this would work for my use-case. The versionMap should be optional but have higher priority than version when it's set. It would be beneficial if CAAPH automatically picks up the version and not through labels ( this will be easier from user perspective, addons will be deployed faster and will not require users to update a label after the upgrade).

from cluster-api-addon-provider-helm.

For this feature - I think we should also consider the use case scope for this add on. If the primary goal is a one-time install, then you should know which version of the helm chart you need to install because you also are installing a specific version of kubernetes.

from cluster-api-addon-provider-helm.

I think we should also consider the use case scope for this add on. If the primary goal is a one-time install,

by add-on i assume you mean CAAPH. For one-time installs there is also ClusterResourceSet from capi itself. Although it doesn't use Helm. From the docs of this repo:

by providing a solution for managing the installation, configuration, upgrade, and deletion of Cluster add-ons using Helm charts

CAAPH already does more than just one-time installs. I was expecting that "smooth" upgrades of add-ons would fall under this scope as well. If this is not the case, i'd like to know now because this is a blocker for us. I understand though that it might take some time to be implemented (if its considered in-scope).

@Jont828 Do you think this is in scope of CAAPH?

from cluster-api-addon-provider-helm.

@nikParasyr - The scope for this project is still open for discussion, which is why I said we should consider it for this add on (yes I meant CAAPH). We should consider upgrade. I do think there is a line at some point where alternative solutions are more appropriate compared to CAAPH. I believe the topic of scope would be a great discussion on the community call, but as I already mentioned to you I'm also happy to have a 1:1 conversation to better understand your requirements/use case.

Furthermore, as this is an open-source project - especially a new one - we are looking for more contributors and maintainers.

from cluster-api-addon-provider-helm.

@nikParasyr For some additional context on scope -- we plan on iterating over the design of this project going forward, and we're currently working on the first iteration with a limited scope (essentially everything listed in the add-on proposal). But the scope of future iterations is up to the community -- as David said, I think it would be good to bring up your concerns about versions in the community call to get a temp read.

from cluster-api-addon-provider-helm.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from cluster-api-addon-provider-helm.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from cluster-api-addon-provider-helm.

/remove-lifecycle rotten

from cluster-api-addon-provider-helm.