-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
OSDOCS#13024: 4.17.11 z-stream RN #86742
base: enterprise-4.17
Are you sure you want to change the base?
Conversation
🤖 Wed Jan 08 14:35:03 - Prow CI generated the docs preview: |
/retest |
3849851
to
1e0b8ce
Compare
/label peer-review-needed |
/remove-label peer-review-needed |
/label peer-review-needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very few comments; Otherwise LGTM
[id="ocp-4-17-11-bug-fixes_{context}"] | ||
==== Bug fixes | ||
|
||
* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver will prevent new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[*OCPBUGS-46429*]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver will prevent new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[*OCPBUGS-46429*]) | |
* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver prevents new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[*OCPBUGS-46429*]) |
|
||
* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver will prevent new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[*OCPBUGS-46429*]) | ||
|
||
* Previously, a hard eviction of a pod in a node caused a pod to enter a termination grace period instead of instantly shutting down and deleted by the kubelet. Each pod that enters a termination grace period exhausts the node's resources. With this release, a bug fix ensures that a pod enters a one-second termination grace period so the kubelet can shut down and then delete the pod. (link:https://issues.redhat.com/browse/OCPBUGS-46364[*OCPBUGS-46364*]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Previously, a hard eviction of a pod in a node caused a pod to enter a termination grace period instead of instantly shutting down and deleted by the kubelet. Each pod that enters a termination grace period exhausts the node's resources. With this release, a bug fix ensures that a pod enters a one-second termination grace period so the kubelet can shut down and then delete the pod. (link:https://issues.redhat.com/browse/OCPBUGS-46364[*OCPBUGS-46364*]) | |
* Previously, a hard eviction of a pod in a node caused a pod to enter a termination grace period instead of instantly shutting down and deleted by the kubelet. Each pod that enters a termination grace period exhausts the node resources. With this release, a bug fix ensures that a pod enters a one-second termination grace period so the kubelet can shut down and then delete the pod. (link:https://issues.redhat.com/browse/OCPBUGS-46364[*OCPBUGS-46364*]) |
https://www.ibm.com/docs/en/ibm-style?topic=grammar-possessives
Do not use possessive ’s with inanimate objects.
|
||
* Previously, the permissions `ec2:AllocateAddress` and `ec2:AssociateAddress` were not verified when the `PublicIpv4Pool` feature was used, which resulted in permission failures during the installation. With this release, the required permissions are validated before the cluster is installed. (link:https://issues.redhat.com/browse/OCPBUGS-46360[*OCPBUGS-46360*]) | ||
|
||
* Previously, users could enter an invalid string for any cpuset in the performance profile, resulting in a broken cluster. With this release, the fix ensures that only valid strings can be entered, eliminating the risk of cluster breakage. (link:https://issues.redhat.com/browse/OCPBUGS-45964[*OCPBUGS-45964*]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Previously, users could enter an invalid string for any cpuset in the performance profile, resulting in a broken cluster. With this release, the fix ensures that only valid strings can be entered, eliminating the risk of cluster breakage. (link:https://issues.redhat.com/browse/OCPBUGS-45964[*OCPBUGS-45964*]) | |
* Previously, users could enter an invalid string for any CPU set in the performance profile, resulting in a broken cluster. With this release, the fix ensures that only valid strings can be entered, eliminating the risk of cluster breakage. (link:https://issues.redhat.com/browse/OCPBUGS-45964[*OCPBUGS-45964*]) |
- CPU set VS the
cpuset
field
If you want to use "cpuset" then should it be in back ticks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @xenolinux! I saw other instances of cpuset without backticks in our docs, so I will change this to CPU set.
@tmalove: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Version(s):
4.17
Issue:
OSDOCS-13024
Link to docs preview:
4.17.11
QE review:
N/A for z-stream release notes.
Additional information:
The errata URLs will return 404 until the go-live date of 01/08/25.