Skip access-control-sys-nice-realtime-capability if there's no nodes using realtime kernel. #2763
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…using realtime kernel. There's no point in running this check if there isn't any node using realtime kernel, so I added a custom skip function for it. Anyway, if nodes with realtime kernel exist, it's still possible/compliant to deploy workload pods in non-realtime kernel nodes, irrespective of the sys_nice cap. For pods deployed in realtime kernel nodes, it's mandatory for this cap to be set at container level.
greyerof
added
non backward compatible
sebrandon1
approved these changes
Feb 5, 2025
|
from change #2763: |
greyerof
added a commit
to greyerof/certsuite
that referenced
this pull request
Feb 5, 2025
I removed the "disable-self-hosted" label from PR redhat-best-practices-for-k8s#2763 but the pre-main self-hosted workflow jobs didn't run. As suggested in github docs, the way to trigger the workflow when a label is added removed is using pull_request's activity types. We did this in the do-not-merge workflow file and it works well there. See https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#label "If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the labeled or unlabeled activity types for the issues, pull_request, pull_request_target, or discussion events instead."
sebrandon1
pushed a commit
that referenced
this pull request
Feb 5, 2025
I removed the "disable-self-hosted" label from PR #2763 but the pre-main self-hosted workflow jobs didn't run. As suggested in github docs, the way to trigger the workflow when a label is added removed is using pull_request's activity types. We did this in the do-not-merge workflow file and it works well there. See https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#label "If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the labeled or unlabeled activity types for the issues, pull_request, pull_request_target, or discussion events instead."
|
from change #2763: |
sebrandon1
merged commit 5b5a939
into
redhat-best-practices-for-k8s:main
39 checks passed
|
from change #2763: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There's no point in running this check if there isn't any node using realtime kernel, so I added a custom skip function for it.
Anyway, if nodes with realtime kernel exist, it's still possible/compliant to deploy workload pods in non-realtime kernel nodes, irrespective of the sys_nice cap. For pods deployed in realtime kernel nodes, it's mandatory for this cap to be set at container level.