-
Notifications
You must be signed in to change notification settings - Fork 73
fix(miniservice): treat webhook-unavailable, EOF, and admission timeout #1554
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
Open
shivakunv
wants to merge
1
commit into
main
Choose a base branch
from
fix-webhook-unavailable-retryable
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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 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.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
Repository: NVIDIA/nvcf
Length of output: 50368
🤖 get_repo_knowledge executed:
get_repo_knowledge NVIDIA/nvcf /tmp/coderabbit-repo-knowledge/nvidia-nvcf-193a0c82/learnings /tmp/coderabbit-repo-knowledge/nvidia-nvcf-193a0c82/conventionsLength of output: 27940
🏁 Script executed:
Repository: NVIDIA/nvcf
Length of output: 50368
🌐 Web query:
Kubernetes corev1 Event Type Warning FailedCreate BindingError EventRecorder contract💡 Result:
The error FailedCreate is a standard Kubernetes event reason indicating that a controller (such as a ReplicaSet, StatefulSet, or Job) was unable to create a requested resource, most commonly a Pod [1][2][3]. This event type is typically marked as Warning and indicates that the resource creation request was rejected or failed before the object could be persisted in etcd [1][3]. Common causes for FailedCreate events include: 1. Admission Webhook Rejection: The most frequent cause is an admission controller (validating or mutating webhook) blocking the request [1][2]. The event message will often contain details from the webhook explaining why the request was denied (e.g., policy violation, missing labels) [1][2]. 2. Resource Quota Exceeded: The request may be blocked because the namespace has reached its resource quota limits [1]. 3. API Server Errors: In some cases, transient timeouts or internal server errors during the API request can trigger this event [4]. A BindingError, while sometimes appearing in related scheduling logs or error messages, refers to a failure in the process of binding a Pod to a Node [5][6]. Pods are created first, then scheduled, and finally bound [1]. If you see a FailedCreate event, it generally means the issue occurred before scheduling, at the admission/creation phase [3]. Conversely, a Binding rejection typically happens after the Pod has been admitted and passed the scheduling phase, often due to conflicts if a scheduler attempts to bind a Pod that is already bound or has been deleted [5][6]. The EventRecorder contract is the mechanism used by controllers to emit these events [7][8]. In Kubernetes Go code, the EventRecorder interface provides methods such as Event, Eventf, and AnnotatedEventf [8][9]. The contract requires: - An object (runtime.Object) that the event concerns [8]. - A string representing the event type (corev1.EventTypeWarning or corev1.EventTypeNormal) [10][8][11]. - A short, unique reason string (like FailedCreate), which is used for programmatic handling [7][8]. - A human-readable message string providing context [7][8]. When writing a custom controller, you use the EventRecorder to report these states to the Kubernetes API, making them visible to users via kubectl describe [7][11]. The controller is responsible for identifying the failure, constructing the event, and calling the recorder to propagate it to the cluster [7][8].
Citations:
🏁 Script executed:
Repository: NVIDIA/nvcf
Length of output: 43978
🌐 Web query:
site:kubernetes.io/docs/reference/kubernetes-api events event type field required Normal Warning Kubernetes Event validation reason type relationship💡 Result:
In the Kubernetes API, the type field in an Event object is a required field that indicates the nature of the event [1]. It is a machine-readable string that must be set to either Normal or Warning for new Events [1][2]. While new types may be introduced in the future, Normal and Warning are the standard classifications used to categorize the significance of the event [1][2]. Regarding the relationship between type and reason, the type field serves as the broad classification (Normal vs. Warning), whereas the reason field (often found in the Event structure as a short, machine-understandable string) provides specific, programmatic details about the underlying cause of the event [1][2]. Although there is no strict schema-level binding between specific types and specific reasons, convention dictates that the reason should be a short, CamelCase string that explains the event's trigger [3]. It is important to note that event consumers should treat these as supplemental, best-effort data, as the specific triggers and messages associated with a reason may evolve over time [4][5].
Citations:
Preserve transient failure events with non-
Warningtypes.parseErrorEventMessagesetsinclude=falsefor transientFailedCreate,FailedUpdate, andBindingErrorevents unlessevent.Type == corev1.EventTypeWarning. Kubernetes does not bind these reasons toWarning, sogetUnexpectedEventsForObjectcan discard a matching event with typeNormalor empty. Returninclude=truefor this branch and add regression coverage.🤖 Prompt for AI Agents