Skip to content
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

PriorityClass follow-ups #1468

Open
olim7t opened this issue Dec 17, 2024 · 0 comments
Open

PriorityClass follow-ups #1468

olim7t opened this issue Dec 17, 2024 · 0 comments

Comments

@olim7t
Copy link
Contributor

olim7t commented Dec 17, 2024

We added support for priorityClassName in #1034.
There were additional suggestions in this comment:

That is, we don't actually check if the PriorityClass exists. Right now that could cause the Pod to have a priorityClassName that points to nothing and this probably prevents the pod from being scheduled correctly. I think this check could be implemented in cass-operator also, I have no preference to that right now.

Second is actually creating PriorityClasses in k8ssandra-operator, but I would have to think about this feature more. Most users should probably set something like preemptionPolicy to Never to prevent new Cassandra pods from killing existing pods. Right now, that would be up to the user to understand what they're doing (like the entire feature, which I think we could consider "experienced users only").

If we use this feature in downstream products, then tracking PodStatus' nominatedNodeName might make sense also. And our PodDisruptionBudget policy is probably not very compatible with this feature either. The scheduling is quite complex on some of these and the documentation is a bit hand waving in some cases "we might or might not do this and maybe something else".

┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: K8OP-301

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: No status
Development

No branches or pull requests

1 participant