-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Support PriorityClass for Longhorn deployment #1487
Comments
Pre-merged Checklist
|
Test Steps:
|
@ttpcodes I've updated the required labels to add automation e2e and docs. I thought it was a modification on the yaml level but since it's in the manager, we need e2e test and docs. It's similar to the taint tolerance feature. |
Also, make sure we've updated the default setting yaml/chart for any new settings. Make sure to test the default setting in the manual test as well. |
Since the previous
|
Verified on master - 07-02-2020 Validation - Passed Scenarios tested:
|
Btw. this wont work at AWS or other public providers which do not have the latest k8s version: |
@ttpcodes Regarding the comment #1487 (comment) , can you check if PriorityClass has Kubernetes version restriction? |
|
@ttpcodes Thanks for clarifying. That should be fine since none of them is the Longhorn default. Also, thanks @runningman84 for reporting. Are you referring to the test steps like @ttpcodes mentioned above, or something else? |
As @ttpcodes mentioned, before |
Maybe you can make the priority only default if k8s version is high enough. What you could also do is creating a own priority class with a similar numeric value as system node critical.... |
@runningman84 you know AWS might take a year or two to move to 1.17 :) @ttpcodes we don't have default priority class right? Users should be able to just leave it blank. |
Yes, there's no default value for the |
That should be good enough for us. |
i## Highlights: 1. [Make Longhorn Helm Chart directly available through Helm repo](longhorn#1043). Now the users can use `helm repo add longhorn https://charts.longhorn.io` to find and install Longhorn easily through Helm command line. 1. [NFS on Longhorn for RWX Access Mode (experimental)](longhorn#1183). We've provided a way to add Longhorn backed NFS provisioner to the cluster, so now user can use `longhorn-nfs` StorageClass to provision RWX volumes. Note: currently NFS provisioner is not highly available. If the node NFS provisioner running is down, the workload using RWX volume might be interrupted for a couple of minutes before restoring the service. Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/rwx-workloads/) for details. 1. Improved Air Gap Environment Support. Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/deploy/airgap/) for updated document for air gap installation. 1. [Remove the air gap image name length limitation](longhorn#1323). 1. [Change the default image pull policy from `Always` to `IfNotPresent`](longhorn#1491) 1. [Aggregate the necessary Docker images](longhorn#1419) 1. [HTTP/HTTPS_PROXY support for S3 backupstore](longhorn#1540) 1. [Support PriorityClass for Longhorn deployment](longhorn#1487). Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/deploy/priority-class/) for details. Live upgrade from v1.0.0 to v1.0.1 is supported. Signed-off-by: Sheng Yang <sheng.yang@rancher.com>
i## Highlights: 1. [Make Longhorn Helm Chart directly available through Helm repo](#1043). Now the users can use `helm repo add longhorn https://charts.longhorn.io` to find and install Longhorn easily through Helm command line. 1. [NFS on Longhorn for RWX Access Mode (experimental)](#1183). We've provided a way to add Longhorn backed NFS provisioner to the cluster, so now user can use `longhorn-nfs` StorageClass to provision RWX volumes. Note: currently NFS provisioner is not highly available. If the node NFS provisioner running is down, the workload using RWX volume might be interrupted for a couple of minutes before restoring the service. Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/rwx-workloads/) for details. 1. Improved Air Gap Environment Support. Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/deploy/airgap/) for updated document for air gap installation. 1. [Remove the air gap image name length limitation](#1323). 1. [Change the default image pull policy from `Always` to `IfNotPresent`](#1491) 1. [Aggregate the necessary Docker images](#1419) 1. [HTTP/HTTPS_PROXY support for S3 backupstore](#1540) 1. [Support PriorityClass for Longhorn deployment](#1487). Check [here](https://staging.longhorn.io/docs/1.0.0/advanced-resources/deploy/priority-class/) for details. Live upgrade from v1.0.0 to v1.0.1 is supported. Signed-off-by: Sheng Yang <sheng.yang@rancher.com>
Have set the priority-class config value to the name of a custom Priority Class and yet none of the Longhorn workloads are using it. Priority for all LH pods remains at 0 - any ideas why? |
@drewhemm Can you file a new issue and add the reproduce steps? |
Sure - here it is: |
Is your feature request related to a problem? Please describe.
This is to avoid the situation where as soon as longhorn-pods are evicted, all other workloads depending on the evicted longhorn-pod can no longer work.
Describe the solution you'd like
In case of resource exhaustion (memory most probably), it would be nice if longhorn can be evicted later than any other "normal" workload
Describe alternatives you've considered
Is there a way to add something like the PriorityClass to leverage the functionality described above.
gz#10575
The text was updated successfully, but these errors were encountered: