[BUG] Helm "harvester" fails with a custom StorageClass set as default

[DovydasNavickas]

Describe the bug

Helm "harvester" in namespace "harvester system" fails upgrade: The number 27855 is a helm revision and the cluster is barely 2d 4h old 🤯 Helm logs:

- [x] KubeVirt Operator                                                                                                           
- [x] KubeVirt Resource named "kubevirt"                                                                                          
- [x] Longhorn                                                                                                                    
- [x] Harvester Network Controller                                                                                                

Please make sure there is a default StorageClass in the Kubernetes cluster.

To Reproduce Steps to reproduce the behavior: This is a fresh cluster with some things configured. I am not sure if it is the case, but my guess is that chart fails upgrade when the default storage class is changed.

I created new storage classes and set one of them as default instead of "harvester-longhorn". After seeing the error message, I set the "harvester-longhorn" to be a default storage class again and the helm upgrade succeeded:

Helm logs stayed the same, so that doesn't seem to be an error message, but just a not about the default storage class.

Expected behavior

A custom storage class can be set as default and harvester helm upgrades would succeed.

Support bundle supportbundle_783c68be-e423-4646-9d1f-df0ff2b4783c_2024-03-23T02-04-43Z.zip

Environment

• Harvester ISO version: 1.3.0
• Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Supermicro baremetal servers.

Additional context Not sure how relevant is this, but I have storage VLAN configured. And my custom StorageClass has 2 replicas, not 3 as the "harvester-longhorn" one.

[DovydasNavickas]

This could be related: https://github.com/longhorn/longhorn/issues/1527#issuecomment-650328255

Install Longhorn v0.8.1 using Rancher. Modify the StorageClass longhorn, e.g. change replica count from 3 to 2. Upgrade to v1.0.0. Observe the upgrade error

Thus, an amount of replicas being set to other than 3 for a default StorageClass would be breaking the helm upgrade. Though that issue is from 2020 and it's closed and seems to be solved.

Could be a confirmation bias.. 😄

[connorkuehl]

Environment Harvester ISO version: 1.3.0

If you installed from 1.3.0, what are you upgrading to with Helm? 1.3.0 is the most current release.

[DovydasNavickas]

I didn't upgrade anything manually, it went into the pending-upgrade cycle itself.

[adamBoualleiguie]

Hello, need to mention other bug (not sure but worth checking), with no upgrade of longhorn , in harvester version 1.3.0 if we edit the number of replica in a storage class and then we create a new VM (note that storage class is default ) the number of replicas for that new vm created is not respecting the updated number in storage class. second scenario: if we create a new storageClass and set it as default then we create a new VM we notice that the number of replica is not respecting the norm , and the number of replica is like the previous storageclass (which is no more the default one)

[atefibra]

Hello, need to mention other bug (not sure but worth checking), with no upgrade of longhorn , in harvester version 1.3.0 if we edit the number of replica in a storage class and then we create a new VM (note that storage class is default ) the number of replicas for that new vm created is not respecting the updated number in storage class. second scenario: if we create a new storageClass and set it as default then we create a new VM we notice that the number of replica is not respecting the norm , and the number of replica is like the previous storageclass (which is no more the default one)

same here !!!!! with Harvester 1.3.0

weird behavior i hope this gets fixed asap @yasker please we need a fix asap, we cannot change the Storage Class replica even when we clone an existing SC and modify the replica number on the new one. I hope you reply to this