jiebi/CodeConvo huggingface dataset:
Change:
WatchEvents, WatchEventsSizes, currentInflightRequests, <ins> requestTerminationsTotal, </ins> } )

Discussion:
What happened: When the kube-apiserver timeouts on a request, we end up doubling the counts measured in : apiserverrequestcounts apiserverrequesttotal apiserverrequestlatencies apiserverrequestlatenciessummary apiserverrequestdurationseconds apiserverresponsesizes What you expected to happen: We only count our requests a single time in our metrics. How to reproduce it (as minimally and precisely as possible): Add a 60 second sleep in the func . You may want to filter by resource (like pods or something) and verb for testing (otherwise this will be quite annoying). Manually hit that endpoint and look at the metric output. /assign
/sig api-machinery instrumentation /cc
Thanks for filing. Can we, while fixing this, add a metric counting timed-out requests? You can't tell from the latency distribution, even if we made the buckets more useful.
Yeah, that's the current plan. I've relayed the idea to offline and he has concurred.
Change:
for i := 0; i < diff; i++ { go func(ix int) { defer wait.Done() <del> if err := jm.podControl.DeletePod(job.Namespace, activePods[ix].Name); err != nil { </del> <ins> if err := jm.podControl.DeletePod(job.Namespace, activePods[ix].Name, job); err != nil { </ins> defer util.HandleError(err) // Decrement the expected number of deletes because the informer won't observe this deletion jm.expectations.DeletionObserved(jobKey)

Discussion:
Currently RC emits an event when it's creating a pod: But nothing is emitted when a pod is deleted. We should create event for scaling both ways. cc
Change:
# Optional: Create autoscaler for cluster's nodes. ENABLE_CLUSTER_AUTOSCALER="${KUBE_ENABLE_CLUSTER_AUTOSCALER:-false}" <del> if [[ "${KUBE_ENABLE_NODE_AUTOSCALER:-false}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then ENABLE_CLUSTER_AUTOSCALER="true" </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> AUTOSCALER_MIN_NODES="${KUBE_AUTOSCALER_MIN_NODES:-}" AUTOSCALER_MAX_NODES="${KUBE_AUTOSCALER_MAX_NODES:-}" AUTOSCALER_ENABLE_SCALE_DOWN="${KUBE_AUTOSCALER_ENABLE_SCALE_DOWN:-true}"

Discussion:
In kube-up we use var while in GKE, documentation, issues etc I think we call it cluster autoscaler. We should make it consistent.
I assume this is what you were already thinking, but: I think we should change it to cluster autoscaler (everywhere). You scale the cluster by adding/removing nodes. You scale a node by adding/removing resources to/from the node, so node autoscaler isn't the right term IMO.
Change:
expectedDevice: "/dev/disk/by-id/wwn-0x000000000", }, <del> // Attach call fails </del> <ins> // Disk is already attached </ins> { <del> name:   "Attach_Negative", attach: attachCall{diskName, nodeName, attachError}, </del> <ins> name:           "Attach_Positive_AlreadyAttached", diskIsAttached: diskIsAttachedCall{diskName, nodeName, false, diskCheckError}, attach:         attachCall{diskName, nodeName, nil}, </ins> test: func(testcase *testcase) (string, error) { attacher := newAttacher(testcase) return attacher.Attach(spec, nodeName) }, <del> expectedError: attachError, </del> <ins> expectedDevice: "/dev/disk/by-id/wwn-0x000000000", </ins> }, // Detach succeeds

Discussion:
Currently we don't check if disk is already attached : from what i remember it can cause some problems, but not sure, sorry for the mass tag
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage /assign
Change:
// nginxImage defined in kubectl.go nginxImageName = "nginx" <del> redisImage     = "gcr.io/google_containers/redis:e2e" </del> <ins> redisImage     = "gcr.io/k8s-testimages/redis:e2e" </ins> redisImageName = "redis" )

Discussion:
Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.
Change:
) func TestMain(m *testing.M) { <ins> // see: https://github.com/kubernetes/kubernetes/issues/104265 setNoUmask() </ins> pkiutiltesting.RunWithPrivateKeyFixtureDirectory(m) }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Running locally. Today? There is none, but I'm not filing this as a flaking test because it's a dependable failure, not a flake. I suspect this depends on the user's umask given the error: originally /area kubeadm /sig cluster-lifecycle
/assign
there were related changes to TestDownloadCerts last month: we could pin the mode for these newly created files in kubeadm. /triage accepted
but the problem seems odd. kubeadm uses client-go utils for writing a cert file with mode 644: i don't understand why something would override this mode to 0640.
i don't understand why something would override this mode to 0640. From the initial issue filing: -- users may be running in an environment with a less permissive umask, but the test depends on a full permissive umask.
ok, right. a quick fix would be to get the current process umask and expect it to be applied to the file permissions: but note: the test should be made Unix only too.
I think it would be reasonable to just set umask without getting it in the TestMain for the package. IIRC go runs tests as a binary / process per package, so it would only affect that package. We could make setting the umask only happen on unix without making the tests unix only as well, by using a conditionally compiled wrapper. I can send a PR for this, I suspect the system umask is google's workstation customization (~~debian testing), and probably relatively unusual elsewhere. I recall now we've run into this in the past during builds where e.g. does not result in the permissions on other systems so we've chmod to e.g.
the test would fail on Windows because -would always return there. so we should os-branch the checks.
I'm not sure I understand the windows part tbh, I think this particular failure can be addressed without affecting windows though. After meetings I got around to confirming on my personal debian stable instance reports while on my "gLinux" (~debian testing) workstation it reports . AFAICT should be more or less the standard across distros but debian and ubuntu at least provide a mechanism out of the box to configure it for the system.

yeah, the test is already broken on non-Unix, so we could just set the umask (syscall.Umask) to make the test happy. the non-Unix fix seems like something that can be done separately.
filed to set it to 0 in test main so it would be technically not umask sensitive anymore on linux and macOS at least.
Change:
// - part 3: other plugins (excluded by part 1 & 2) in regular extension point. newPlugins := reflect.New(reflect.TypeOf(e.slicePtr).Elem()).Elem() // part 1 <del> for _, name := range enabledSet.list { </del> <ins> for _, name := range slice.CopyStrings(enabledSet.list) { </ins> if overridePlugins.has(name) { newPlugins = reflect.Append(newPlugins, reflect.ValueOf(pluginsMap[name])) enabledSet.delete(name)

Discussion:
Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <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 scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.
Change:
actualSum := actualHist.GetSampleSum() num := math.Abs(actualSum - ee.sum) den := math.Max(math.Abs(actualSum), math.Abs(ee.sum)) <del> if num > den/1e14 { t.Errorf("At idx=%d, expected sum %v but got %v, err=%v", idx, ee.sum, actualSum, actualSum-ee.sum) </del> <ins> relErr := num / den // Issue 120112 reports relative errors as high as 9.55994394104272e-14 if relErr > 1e-13 { t.Errorf("At idx=%d, expected sum %v but got %v, err=%v, relativeErr=%v", idx, ee.sum, actualSum, actualSum-ee.sum, relErr) </ins> } } }

Discussion:
pull-kubernetes-unit see title 8/17? ref No response /sig instrumentation
/triage accepted /assign
an example flake in of sig-release/master-blocking test grid. (It flakes a few times, and it is not a blocker.)
/cc still flake
I tested it locally, and it did reproduce the error. I'll take a look at this problem.
I looked into this part of the code. The problem should be the loss of precision. as the denominator of is too large, that is to say, occasionally satisfies the condition( ≈0.16%), and the allowed precision error is too small. So, occasionally this test flakes. I modified the code and printed out the results of in the log(It can be seen that the value is greater than ): see stress test result details from the . I don't know much about this, how did you decide to use as the denominator? Maybe we can adjust the precision error( for example 1e-14 -1e-13 or other value)? Can you take a look? FYI: In the prometheus histogram test , this error value is set to
I do not recall exactly how I arrived at the limit of 1e-14. That is about 46.5 bits, which should be well within the accuracy of a . To get this test passing, I have increased the limit by a factor of 10 (in ), based on the relative errors reported above.
Change:
}, }, }, <ins> { name: "update existing instance with .spec.ordinals.start", old: apps.StatefulSet{ ObjectMeta: metav1.ObjectMeta{Name: "abc.123.example", Namespace: metav1.NamespaceDefault}, Spec: apps.StatefulSetSpec{ PodManagementPolicy: apps.OrderedReadyPodManagement, Selector:            &metav1.LabelSelector{MatchLabels: validLabels}, Template:            validPodTemplate.Template, UpdateStrategy:      apps.StatefulSetUpdateStrategy{Type: apps.RollingUpdateStatefulSetStrategyType}, }, }, update: apps.StatefulSet{ ObjectMeta: metav1.ObjectMeta{Name: "abc.123.example", Namespace: metav1.NamespaceDefault}, Spec: apps.StatefulSetSpec{ PodManagementPolicy: apps.OrderedReadyPodManagement, Selector:            &metav1.LabelSelector{MatchLabels: validLabels}, Template:            validPodTemplate.Template, UpdateStrategy:      apps.StatefulSetUpdateStrategy{Type: apps.RollingUpdateStatefulSetStrategyType}, Ordinals: &apps.StatefulSetOrdinals{ Start: 3, }, }, }, }, </ins> } errorCases := []testCase{

Discussion:
This applies to StatefulSetStartOrdinal feature gate. Field validation should be done regardless of the feature gate state. From
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
/assign
/sig apps
Change:
kubectl run testmetadata --image=nginx --replicas=2 --port=80 --expose --service-overrides='{ "metadata": { "annotations": { "zone-context": "home" } } } ' # Check result kube::test::get_object_assert deployment "{{range.items}}{{$id_field}}:{{end}}" 'testmetadata:' <del> kube::test::get_object_assert 'service testmetadata' "{{.metadata.annotations}}" "map[endpointslice.kubernetes.io/managed-by-setup:true zone-context:home]" </del> <ins> kube::test::get_object_assert 'service testmetadata' "{{.metadata.annotations}}" "map[zone-context:home]" </ins> ### Expose deployment as a new service # Command kubectl expose deployment testmetadata  --port=1000 --target-port=80 --type=NodePort --name=exposemetadata --overrides='{ "metadata": { "annotations": { "zone-context": "work" } } } ' # Check result <del> kube::test::get_object_assert 'service exposemetadata' "{{.metadata.annotations}}" "map[endpointslice.kubernetes.io/managed-by-setup:true zone-context:work]" </del> <ins> kube::test::get_object_assert 'service exposemetadata' "{{.metadata.annotations}}" "map[zone-context:work]" </ins> # Clean-Up # Command

Discussion:
What happened: kube-controller-manager panic for What you expected to happen: no panic. How to reproduce it (as minimally and precisely as possible): No idea. I guess it's hard to reproduce. Anything else we need to know?: Found from here: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign cc Should we do something for v1.17? (v1.17 code freeze now, but still have the opportunity to fix) can be removed safely in v1.18, right?
/sig scheduling
Working on this in /sig network /priority critical-urgent /assign
Sorry, I didn't realize it. I should have a search before firing an issue. I recommend adding this issue to your PR. e.g. `
Updated, thanks!
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This seems to be writing to a cached (should be const) service. I think we need to DeepCopy() it before we mutate the Go type. does that sound right? Is this still our best state of the art?
yes, copy before change
we have a tool to catch this (the cache mutation detector), but it got disabled in our test runs two years ago (xref )
yes great catch - I was always convinced this is enabled...
Change:
client internalclientset.Interface // these flags control which items will be checked to deny exec/attach <del> hostIPC    bool hostPID    bool privileged bool </del> <ins> hostNetwork bool hostIPC     bool hostPID     bool privileged  bool </ins> } var _ admission.ValidationInterface = &DenyExec{}

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: currently only are checked in admission controller What you expected to happen: hostNetwork should also be checked to deny exec /attach How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind bug /sig auth
cc
Change:
}) } <ins> // NOTE(resouer): nodeInformer to substitute deprecated taint key (notReady -> not-ready). // Remove this logic when we don't need this backwards compatibility nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: util.CreateAddNodeHandler(func(node *v1.Node) error { return nc.doFixDeprecatedTaintKeyPass(node) }), UpdateFunc: util.CreateUpdateNodeHandler(func(_, newNode *v1.Node) error { return nc.doFixDeprecatedTaintKeyPass(newNode) }), }) </ins> nc.nodeLister = nodeInformer.Lister() nc.nodeInformerSynced = nodeInformer.Informer().HasSynced

Discussion:
Almost all style strings use dashes, rather than javascript names. vs .
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Thanks for notification, a quick fix is submitted.
/cc
The PR here isn't merged yet. Can we make that happen please? We're still in alpha, so should be ok
Should I add the v1.8 milestone to this issue?
Hope so. We are pending in , need approve from
I opened with safe changes. "not-ready" change needs to be discussed more, as it's a breaking change. I believe it's best with fixing that to the time we'll be moving to beta, as we'll need to do another breaking change, i.e. remove 'alpha' from the key.
Aren't we doing this at the 11th hour? Is this going to hit 1.8?
Strings like this that are part of the core API should be part of a design doc that is formally reviewed by an API group. We need to find ways to catch this stuff earlier. We should also have an evolving API style guide that lists stuff like this. /cc
Thanks , let me make some summary: quick fix for 1.8 is , will be merged soon. final fix is , we are collaborating to reach a final solution and it's not target 1.8
Agree with Joe, can someone open a PR to that documents that taint names should follow the naming conventions for annotations?
Change:
trap "teardown" EXIT <del> POD_ID_LIST=$($CLOUDCFG -json -l name=myNginx list pods | jq ".items[].id") </del> <ins> POD_ID_LIST=$($CLOUDCFG '-template={{range.Items}}{{.ID}} {{end}}' -l name=myNginx list pods) </ins> # Container turn up on a clean cluster can take a while for the docker image pull. ALL_RUNNING=0 while [ $ALL_RUNNING -ne 1 ]; do

Discussion:
We have an e2e test that runs the guestbook example. We should also have one that runs through the other example.
Change:
"BackendConfig":         true, "NodeMetrics":           true, "PodMetrics":            true, <del> "ScalingPolicy":         true, </del> "VolumeSnapshotClass":   true, "VolumeSnapshotContent": true, "VolumeSnapshot":        true, <del> // A CRD created by other e2e tests without any test data. "Noxu": true, </del> } apiGroups, err := c.Discovery().ServerPreferredResources()

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-master-scale-correctness Which test(s) are failing: [sig-cli] Kubectl client kubectl get output should contain custom columns for each resource Since when has it been failing: 11/6 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: n/a /sig cli /sig scalability /cc
The label(s) cannot be applied. These labels are supported: <detailsIn response to : <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --gce-master-scale-correctness [sig-cli] Kubectl client kubectl get output should contain custom columns for each resource 11/6 https://k8s- Anything else we need to know: n/a /sig scalability /cc 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
Doesn't seem to be scale-related - failed for me the same way in the presubmit:
- do we run correctness test in smaller scale (so we can detect whether failures are scale related or not)? I can't find them on neither https://k8s- nor https://k8s- dashboards.
This is a new test that seem to be flaky at head: - seems that you this in Can you please take a look?
/assign
/reopen Let's wait for the test to pass /assign
Reopened this issue. <detailsIn response to : /reopen /assign 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
That seems to be creating one of every object from the etcd data test in an e2e test. The failing object looks like a node object, which is likely getting deleted by the Node controller as soon as it is created.
opened to skip nodes for this test
/reopen The job is not green
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
failed test run started from a commit prior to the fix merging ( started from ) /close
Closing this issue. <detailsIn response to : failed test started from a commit prior to the fix merging ( started from ) 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
Change:
} } <ins> func TestValidateObjectMetaUpdateIgnoresCreationTimestamp(t *testing.T) { if errs := ValidateObjectMetaUpdate( &api.ObjectMeta{Name: "test", CreationTimestamp: util.NewTime(time.Unix(10, 0))}, &api.ObjectMeta{Name: "test"}, ); len(errs) != 0 { t.Fatalf("unexpected errors: %v", errs) } if errs := ValidateObjectMetaUpdate( &api.ObjectMeta{Name: "test"}, &api.ObjectMeta{Name: "test", CreationTimestamp: util.NewTime(time.Unix(10, 0))}, ); len(errs) != 0 { t.Fatalf("unexpected errors: %v", errs) } if errs := ValidateObjectMetaUpdate( &api.ObjectMeta{Name: "test", CreationTimestamp: util.NewTime(time.Unix(11, 0))}, &api.ObjectMeta{Name: "test", CreationTimestamp: util.NewTime(time.Unix(10, 0))}, ); len(errs) != 0 { t.Fatalf("unexpected errors: %v", errs) } } </ins> // Ensure trailing slash is allowed in generate name func TestValidateObjectMetaTrimsTrailingSlash(t *testing.T) { errs := ValidateObjectMeta(&api.ObjectMeta{Name: "test", GenerateName: "foo-"}, false, nameIsDNSSubdomain)

Discussion:
After the DST change: We should be ignoring creationTimestamp on update.
Could you please explain the cause of the failure in more detail? Do we not normalize the timezone in the representation used in the API?
When we serialize to JSON we are using a value that has a timezone embedded in it (time.Time). As a result the representation changed. We should normalize it as well during serialization, but in general creationTimestamp should not prevent an update since it can safely be ignored.
I think we should allow creationTimestamp to be empty and also convert time to UTC() before marshaling.
More specifically: We'd also want to change: to and to
Makes sense to me - clients should always control their timezone and with distributed masters you might see different values. ----- Original Message -----
I'll own the follow up on this. ----- Original Message -----
+1 for UTC serialization
Opened to marshal to utc when serializing