PhanLe1010

> Since the upgrade sequence includes the pre-upgrade check, which failed (although the reason for the failure is not exposed) no running longhorn components have been altered. Intervention is simply...

> So no other rollback is needed. The helmchart can stay in place - no action will be taken until it is modified. However, the reason for the failure is...

> Note: the helmchart controller will create another upgrade job an hour later, it appears. But don't attempt to prevent that by deleting the helmchart. That implies an uninstall: Maybe...

> Deleting the most recent helm.sh secret and then touching the HelmChart will lead it to start over from the top, and re-run everything, including the longhorn pre-upgrade check. Sounds...

Workaround: 1. Remove the taint 2. Scale down the workload 3. Add the taint 4. Scale back the workload

I agree with the investigation from @ejweber ! > Remove the NoExecute taint. Use a combination of a NoSchedule taint and manual pod deletion to move workloads off the node...

I think we also need to cleanup the orphan tgt and iscsi session as mentioned at https://github.com/longhorn/longhorn/issues/7386#issuecomment-2195984587 . WDYT?

> > I think we also need to cleanup the orphan tgt and iscsi session as mentioned at [#7386 (comment)](https://github.com/longhorn/longhorn/issues/7386#issuecomment-2195984587) . WDYT? > > Do you mean cleaning up iscsi...

> no PriorityClass with name db-very-high-priority was found Is there something wrong with priorityclass? Can you provide: 1. `kubectl -n longhorn-system get settings.longhorn.io | grep priority-class` 2. And `kubectl get...

Hi @ming1 Thank you very much for the explanation! Yeah, it totally makes sense as you already have a lot of other works and it would be too much effort...