jiebi/CodeConvo huggingface dataset:
Change:
[sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support can read and write file to remote SMB folder [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end May 24 2022 I think it is related to these setup steps No response_ /sig windows
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
bindClusterRBACRoleToServiceAccount(ctx, f, s, "cluster-admin") installSteps := []string{ <del> "echo "@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing/" >> /etc/apk/repositories", "&& apk add kubectl@testing gettext openssl", </del> <ins> "echo "@community http://dl-cdn.alpinelinux.org/alpine/edge/community/" >> /etc/apk/repositories", "&& apk add kubectl@community gettext openssl", </ins> "&& apk add --update coreutils", fmt.Sprintf("&& curl %s > gmsa.sh", gmsaWebhookDeployScriptURL), "&& chmod +x gmsa.sh",
Change:
When API fails there is no way to understand what happens because error is not reported. Error should be either logged or, better event should be recorded, so user would see it in the output. this patch to the kubernetes sources: a pod: the pod details: is not mentioning why pod is in pending state. No response <details</details<detailslocal </details<details</details<details</details<details</details<details</details
/sig node
/assign /cc
Logging is not enough, users don't have access to kubelet logs. Let's generate an event. I don't know whether we should have a well-defined condition for this. Thoughts anyone?
+1 on a condition.
From
In I am proposing as new pod condition.
/triage accepted /priority important-soon Is it a bug or a feature? Will it be tracked as a part of the enhancement work? If so we can close this one
/cc
/cc
Can you explain why do you prefer a condition over an event?
Depends on expectations :sweatsmile: The : . I expected this to be done already as part of the initial implementation, which would make this a bug. But one can also argue that this particular part had been deferred until later, which makes this a feature. We are using separate issues to track individual aspects of the enhancement work, so let's keep this open. Let's focus on adding the event in this issue and discuss the condition in

Discussion:
FailedCreatePodSandBox               = "FailedCreatePodSandBox" FailedStatusPodSandBox               = "FailedPodSandBoxStatus" FailedMountOnFilesystemMismatch      = "FailedMountOnFilesystemMismatch" <ins> FailedPrepareDynamicResources        = "FailedPrepareDynamicResources" </ins> ) // Image manager event reason list

// Prepare resources allocated by the Dynammic Resource Allocation feature for the pod if utilfeature.DefaultFeatureGate.Enabled(features.DynamicResourceAllocation) { <del> if m.runtimeHelper.PrepareDynamicResources(pod) != nil { </del> <ins> if err := m.runtimeHelper.PrepareDynamicResources(pod); err != nil { ref, referr := ref.GetReference(legacyscheme.Scheme, pod) if referr != nil { klog.ErrorS(referr, "Couldn't make a ref to pod", "pod", klog.KObj(pod)) return } m.recorder.Eventf(ref, v1.EventTypeWarning, events.FailedPrepareDynamicResources, "Failed to prepare dynamic resources: %v", err) klog.ErrorS(err, "Failed to prepare dynamic resources", "pod", klog.KObj(pod)) </ins> return } }
Change:
Similar to and easily reproducible. The handler occasionally completes and sends a response before timing out. /kind failing-test /kind flake /sig api-machinery
/assign
/assign Thank you very much for fixing these tests.
/triage accepted

Discussion:
}) } <ins> testDone := make(chan struct{}) defer close(testDone) </ins> ts := httptest.NewServer( withDeadline( WithTimeoutForNonLongRunningRequests(

if err != nil { t.Fatal(err) } <del> if res.StatusCode != http.StatusGatewayTimeout { t.Errorf("got res.StatusCde %d; expected %d", res.StatusCode, http.StatusServiceUnavailable) </del> <ins> if actual, expected := res.StatusCode, http.StatusGatewayTimeout; actual != expected { t.Errorf("got status code %d; expected %d", actual, expected) </ins> } res.Body.Close() }

}) } <ins> testDone := make(chan struct{}) defer close(testDone) </ins> ts := httptest.NewServer( WithHTTPLogging( withDeadline(

cancel() // mutate request Headers // Authorization filter does it for example <del> for j := 0; j < 10000; j++ { req.Header.Set("Test", "post") </del> <ins> for { select { case <-testDone: return default: req.Header.Set("Test", "post") } </ins> } }), func(r *http.Request, requestInfo *request.RequestInfo) bool {

if err != nil { t.Fatal(err) } <del> if res.StatusCode != http.StatusGatewayTimeout { t.Errorf("got res.StatusCode %d; expected %d", res.StatusCode, http.StatusServiceUnavailable) </del> <ins> if actual, expected := res.StatusCode, http.StatusGatewayTimeout; actual != expected { t.Errorf("got status code %d; expected %d", actual, expected) </ins> } res.Body.Close() }
Change:
I have created the following secret in my cluster. When I add labels to my secret and try to apply it in the cluster I get the following error This also happens when I use or using the go client. Not sure why, but works. I expect that the secret can be updated with the new labels since the is not actually changed. Steps explained above. No response <details</details<detailsKind </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
/assign
/remove-sig cli /sig apps

Discussion:
} <del> // FromUnstructuredWIthValidation converts an object from map[string]interface{} representation into a concrete type. </del> <ins> // FromUnstructuredWithValidation converts an object from map[string]interface{} representation into a concrete type. </ins> // It uses encoding/json/Unmarshaler if object implements it or reflection if not. // It takes a validationDirective that indicates how to behave when it encounters unknown fields. func (c *unstructuredConverter) FromUnstructuredWithValidation(u map[string]interface{}, obj interface{}, returnUnknownFields bool) error {

} dv.SetBytes(data) } else { <del> dv.Set(reflect.Zero(dt)) </del> <ins> dv.Set(reflect.MakeSlice(dt, 0, 0)) </ins> } return nil }

G []int             `json:"fg"` H []bool            `json:"fh"` I []float32         `json:"fi"` <ins> J []byte            `json:"fj"` </ins> } type G struct {

obj:  &F{}, }, { <ins> data: "{"fj":""}", obj:  &F{}, }, { </ins> // Invalid string data data: "{"fa":123}", obj:  &F{},
Change:
sig-node : DRA related tests are failing and 2 other DRA related tests. Both jobs started failing on 7th June As per the logs DRA plugin is not getting registered to kubelet Jobs started failing after merging As per , CDI is not available out of the box for containerd which may be the reason for failure of the jobs. /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/cc
Looks like I shouldn't have labeled DRA Node tests as NodeFeature. However, re-labeling it NodeAlphaFeature would not work either - would start to fail. I'm going to remove . This should help.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Not fixed yet, pending

Discussion:
podInPendingStateTimeout  = time.Second * 60 // how long to wait for a pod to stay in pending state ) <del> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation][NodeFeature:DynamicResourceAllocation]", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation]", func() { </ins> f := framework.NewDefaultFramework("dra-node") f.NamespacePodSecurityEnforceLevel = admissionapi.LevelBaseline
Change:
sig-node : DRA related tests are failing and 2 other DRA related tests. Both jobs started failing on 7th June As per the logs DRA plugin is not getting registered to kubelet Jobs started failing after merging As per , CDI is not available out of the box for containerd which may be the reason for failure of the jobs. /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/cc
Looks like I shouldn't have labeled DRA Node tests as NodeFeature. However, re-labeling it NodeAlphaFeature would not work either - would start to fail. I'm going to remove . This should help.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Not fixed yet, pending

Discussion:
podInPendingStateTimeout  = time.Second * 60 // how long to wait for a pod to stay in pending state ) <del> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation]", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation][NodeAlphaFeature:DynamicResourceAllocation]", func() { </ins> f := framework.NewDefaultFramework("dra-node") f.NamespacePodSecurityEnforceLevel = admissionapi.LevelBaseline
Change:
// RecommendedDefaultAttachDetachControllerConfiguration defaults a pointer to a // AttachDetachControllerConfiguration struct. This will set the recommended default // values, but they may be subject to change between API versions. This function // is intentionally not registered in the scheme as a "normal" // function to allow consumers of this type to set whatever defaults for their // embedded configs. Forcing consumers to use these defaults would be problematic // as defaulting in the scheme is done as part of the conversion, and there would // be no easy way to opt-out. Instead, if you want to use this defaulting method // run it in your wrapper struct of this type in its method. func RecommendedDefaultAttachDetachControllerConfiguration(obj kubectrlmgrconfigv1alpha1.AttachDetachControllerConfiguration) { zero := metav1.Duration{} if obj.ReconcilerSyncLoopPeriod == zero { obj.ReconcilerSyncLoopPeriod = metav1.Duration{Duration: 60 time.Second} } } Default is set to 60 second. but, the comment said is 5 seconds. // AttachDetachControllerConfiguration contains elements describing AttachDetachController. type AttachDetachControllerConfiguration struct { // Reconciler runs a periodic loop to reconcile the desired state of the with // the actual state of the world by triggering attach detach operations. // This flag enables or disables reconcile. Is false by default, and thus enabled. DisableAttachDetachReconcilerSync bool // ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop // wait between successive executions. Is set to 5 sec by default. ReconcilerSyncLoopPeriod metav1.Duration } default should change to 60 seconds. comment errror None <detailsall version until now </details<detailsnot relevent </details<details</details<details</details<details</details<details</details
/sig storage
/remove-kind api-change /kind cleanup
Those labels are not set on the issue: <detailsIn response to : /remove-kind api-change /kind cleanup Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted

Discussion:
}, "ReconcilerSyncLoopPeriod": { SchemaProps: spec.SchemaProps{ <del> Description: "ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop wait between successive executions. Is set to 5 sec by default.", </del> <ins> Description: "ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop wait between successive executions. Is set to 60 sec by default.", </ins> Default:     0, Ref:         ref("k8s.io/apimachinery/pkg/apis/meta/v1.Duration"), },

// This flag enables or disables reconcile.  Is false by default, and thus enabled. DisableAttachDetachReconcilerSync bool // ReconcilerSyncLoopPeriod is the amount of time the reconciler sync states loop <del> // wait between successive executions. Is set to 5 sec by default. </del> <ins> // wait between successive executions. Is set to 60 sec by default. </ins> ReconcilerSyncLoopPeriod metav1.Duration }
Change:
There's been a quite a few failures across jobs that query node metrics. The test is Last passing - First failing - appears to point to which is bump in prometheus client library. Possibly related? /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Verified with presubmit that reverting the prometheus client library results in the test passing. Opened PR for revert in
/cc
/assign
thanks for filing this issue! I think seems like a promising fix (thanks ) and there's a fair chance we won't need the revert
ack, thanks for the fix, it seems we can go with that then and hold the revert.

Discussion:
"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically("==", value), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }

"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically(">=", lower), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }

gomega.BeTemporally(">=", time.Now().Add(-maxStatsAge)), // Now() is the test start time, not the match time, so permit a few extra minutes. gomega.BeTemporally("<", time.Now().Add(2*time.Minute))), <del> )})) </del> <ins> ), "Histogram": gstruct.Ignore(), })) </ins> }

"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically(">", value), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }
Change:
When running an extension apiserver, the resouces and groups served by this apiserver are missing from openapi/v3 discovery from time to time (approx 1 in 100 requests). the requests should pass 100% of the time repeat 100 times and end up with we can see it is missing in the openapi/v3 endpoint No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted /cc

Discussion:
if apiServiceInfo, ok := s.apiServiceInfo[apiservice.Name]; ok { apiServiceInfo.apiService = *apiservice apiServiceInfo.handler = handler <ins> return </ins> } s.apiServiceInfo[apiservice.Name] = &openAPIV3APIServiceInfo{ apiService: *apiservice,
Change:
master-blocking Conformance - GCE - master - kubetest2Kubernetes e2e suite. ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test ! 2023-06-27 16:43 PDT Kubernetes e2e suite: [It] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] No response /sig cloud-provider /sig apps cc
This is more critical than I expected it starts to fail in other jobs ,%20master ,%20ipvs,%20dual,%20master From the diff the best candidate seems can you PTAL /priority critical-urgent
/assign
anyone from you can please add to this issue?
/triage accepted
I have a proposed fix in . Is there a job I can add?
/remove-kind failing-test /kind flake

Discussion:
"k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/selection" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets"

// node selectors labels to namespaces var NamespaceNodeSelectors = []string{"scheduler.alpha.kubernetes.io/node-selector"} <ins> var nonTerminalPhaseSelector = func() labels.Selector { var reqs []labels.Requirement for _, phase := range []v1.PodPhase{v1.PodFailed, v1.PodSucceeded} { req, _ := labels.NewRequirement("status.phase", selection.NotEquals, []string{string(phase)}) reqs = append(reqs, *req) } selector := labels.NewSelector() return selector.Add(reqs...) }() </ins> type updateDSFunc func(*appsv1.DaemonSet) // updateDaemonSetWithRetries updates daemonsets with the given applyUpdate func

func listDaemonPods(ctx context.Context, c clientset.Interface, ns string, label map[string]string) *v1.PodList { selector := labels.Set(label).AsSelector() <del> options := metav1.ListOptions{LabelSelector: selector.String()} </del> <ins> options := metav1.ListOptions{ LabelSelector: selector.String(), FieldSelector: nonTerminalPhaseSelector.String(), } </ins> podList, err := c.CoreV1().Pods(ns).List(ctx, options) framework.ExpectNoError(err) gomega.Expect(podList.Items).ToNot(gomega.BeEmpty())
Change:
In asked the following question. While the user-facing documentation answers this question clearly enough, John was reading the HELP string in the Prometheus scrapes. That thing only says the following. The metric HELP strings should be clear enough. Scrape or read the code (). No response <detailsThis problem started when we generalized to allow width other than 1 and got worse when we introduced borrowing. </details<detailsN/A </details<detailsN/A </details<details</details<details</details<details</details
/assign
Actually, this metric should be removed. It is a duplicate of but with an inferior name.
Looks good (Sorry I never got around to logging this issue myself. Have been super busy. And your wording is better anyway :-) )
/triage accepted Thank you.

Discussion:
) apiserverRequestConcurrencyLimit = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Namespace:      namespace, Subsystem:      subsystem, Name:           "request_concurrency_limit", Help:           "Shared concurrency limit in the API Priority and Fairness subsystem", StabilityLevel: compbasemetrics.ALPHA, </del> <ins> Namespace: namespace, Subsystem: subsystem, Name:      "request_concurrency_limit", Help:      "Nominal number of execution seats configured for each priority level", // Remove this metric once all suppported releases have the equal nominal_limit_seats metric DeprecatedVersion: "1.30.0", StabilityLevel:    compbasemetrics.ALPHA, </ins> }, []string{priorityLevel}, )

) apiserverRequestConcurrencyInUse = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Namespace:         namespace, Subsystem:         subsystem, Name:              "request_concurrency_in_use", Help:              "Concurrency (number of seats) occupied by the currently executing (initial stage for a WATCH, any stage otherwise) requests in the API Priority and Fairness subsystem", DeprecatedVersion: "1.28.0", </del> <ins> Namespace: namespace, Subsystem: subsystem, Name:      "request_concurrency_in_use", Help:      "Concurrency (number of seats) occupied by the currently executing (initial stage for a WATCH, any stage otherwise) requests in the API Priority and Fairness subsystem", // Remove this metric once all suppported releases have the equal current_executing_seats metric DeprecatedVersion: "1.31.0", </ins> StabilityLevel:    compbasemetrics.ALPHA, }, []string{priorityLevel, flowSchema},
Change:
PriorityPidEvictionOrdering [Slow] [Serial] [Disruptive][NodeFeature:Eviction] when we run containers that should cause PIDPressure should eventually evict all of the correct pods /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node /assign /priority important-soon
fork-bomb-container-container exited with code 2. I tried to create a pod in my env of containerd: The pod can be running and it works as designed. I need to test it in cri-o later.
/cc
/triage accepted

Discussion:
var _ = SIGDescribe("PriorityPidEvictionOrdering [Slow] [Serial] [Disruptive][NodeFeature:Eviction]", func() { f := framework.NewDefaultFramework("pidpressure-eviction-test") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged <del> pressureTimeout := 2 * time.Minute </del> <ins> pressureTimeout := 3 * time.Minute </ins> expectedNodeCondition := v1.NodePIDPressure expectedStarvedResource := noStarvedResource
Change:
from: from: CauseType and field.ErrorType should be exactly mapped according to the comment of ErrorType, but currently this is not the case, metav1.CauseType is missing several values none No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted

Discussion:
// CauseTypeFieldValueNotSupported is used to report valid (as per formatting rules) // values that can not be handled (e.g. an enumerated string). CauseTypeFieldValueNotSupported CauseType = "FieldValueNotSupported" <ins> // CauseTypeForbidden is used to report valid (as per formatting rules) // values which would be accepted under some conditions, but which are not // permitted by the current conditions (such as security policy).  See // Forbidden(). CauseTypeForbidden CauseType = "FieldValueForbidden" // CauseTypeTooLong is used to report that the given value is too long. // This is similar to ErrorTypeInvalid, but the error will not include the // too-long value.  See TooLong(). CauseTypeTooLong CauseType = "FieldValueTooLong" // CauseTypeTooMany is used to report "too many". This is used to // report that a given list has too many items. This is similar to FieldValueTooLong, // but the error indicates quantity instead of length. CauseTypeTooMany CauseType = "FieldValueTooMany" // CauseTypeInternal is used to report other errors that are not related // to user input.  See InternalError(). CauseTypeInternal CauseType = "InternalError" // CauseTypeTypeInvalid is for the value did not match the schema type for that field CauseTypeTypeInvalid CauseType = "FieldValueTypeInvalid" </ins> // CauseTypeUnexpectedServerResponse is used to report when the server responded to the client // without the expected return type. The presence of this cause indicates the error may be // due to an intervening proxy or the server software malfunctioning.