https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# longhorn-storage
a
This message was deleted.
f
Yes, this is still the case. There is no concept of a PV or PVC priority class in Longhorn. The "priority-class" setting is really just a way to get the 
spec.priorityClassName
on all Longhorn pods so they will not (hopefully) not be evicted. A single 
instance-manager
pod runs all necessary engines and replicas on each node. So, a successful update of the "priority-class" setting necessarily restarts each 
instance-manager
pod with the new value. The restart would crash any engines or replicas running inside that 
instance-manager
, so we disallow attached volumes while it is modified. The only other obvious behavior I can think of would be a "lazy" update where we changed the 
spec.priorityClassName
on Longhorn pods when we started or restarted them, but not if they were running. (Maybe this is what you're getting at?) I don't think this would be very useful, because 
instance-manager
pods are very rarely restarted. (Even if a node doesn't have any workloads on it, it may be running replicas for volumes attached elsewhere.) So changing the "priority-class" setting would have virtually no immediate benefit (which could be quite confusing). Note that even during upgrades we don't require 
instance-manager
to be restarted (as this would disrupt workloads). Instead, we start a new 
instance-manager
and only clean up the old one when all the processes running inside it are gone. If you still think a change in behavior (or the addition of an optional behavior) makes sense given this context, I encourage you to open a feature request at https://github.com/longhorn/longhorn!
c
About this lazy update: I think it would be better than nothing. Currently (using the default PC), if there is some hiccup and a longhorn instance is killed, it ends up that the whole node is affected by some NFS-server-not-responding-still-trying nightmare problem. The only reliable way out of this seems to be a reboot of the node. This is much worse.
Does Longhorn create its own priority class at new installations? I haven't found a longhorn-specific PC on my existing nodes, but they are still using version 1.5.1. AFAIR there was a recommendation somewhere to reuse the system-cluster-critical or system-node-critical PC. Having a dedicated "longhorn-critical" priority class would make this more flexible. Maybe it would be reasonable to give the instance manager an even higher PC than other longhorn pods to support a clean shutdown sequence within the node.
f
Cool, thanks! Also follow https://github.com/longhorn/longhorn/issues/7173 for a discussion on how these settings will be updated in the future.
Open in Slack
PreviousNext
Powered by