jiebi/CodeConvo huggingface dataset:
Change:
return copyService } <ins> func updateServiceLoadBalancerIP(service *v1.Service, serviceIP string) *v1.Service { copyService := service.DeepCopy() if len(serviceIP) > 0 && copyService != nil { copyService.Spec.LoadBalancerIP = serviceIP } return copyService } </ins> func (az *Cloud) findServiceIPAddress(ctx context.Context, clusterName string, service *v1.Service, isInternalLb bool) (string, error) { if len(service.Spec.LoadBalancerIP) > 0 { return service.Spec.LoadBalancerIP, nil

Discussion:
/kind bug What happened: ILB Frontend IP configuration does not change while updating service What you expected to happen: LB Frontend IP configuration should get updated How to reproduce it (as minimally and precisely as possible): Source issue : AKS service is created using .yaml manifest. ILB is described as it is shown in the documentation: annotations: "true" spec: ports: port: 80 type: LoadBalancer loadBalancerIP: 10.240.200.2 ILB instance with the "kubernetes-internal" name is created with a correct private IP address pointing to the service described. If I change the "loadBalancerIP" to another internal IP address and re-deploy the service, the last is deployed with the correct new IP address, but "kubernetes-internal" ILB still has the old Frontend IP configuration. Environment: Cloud provider or hardware configuration: Azure
/sig azure
This also not works for public LB. /cc Could you fix the bug and cherry pick to old versions?
I got this bug today, I changed the external LoadBalancerIP on a LoadBalancer service. The service event log showed that it immediately recognised the change ("oldIP =newIP") but I had to delete/recreate the service to see the change in the Azure loadbalancer.
Change:
framework.ExpectNoError(err, "failed to create nvidia-driver-installer daemonset") framework.Logf("Successfully created daemonset to install Nvidia drivers.") <del> pods, err := framework.WaitForControlledPods(f.ClientSet, ds.Namespace, ds.Name, apps.Kind("DaemonSet")) </del> <ins> pods, err := framework.WaitForControlledPods(f.ClientSet, ds.Namespace, ds.Name, extensionsinternal.Kind("DaemonSet")) </ins> framework.ExpectNoError(err, "failed to get pods controlled by the nvidia-driver-installer daemonset") <del> devicepluginPods, err := framework.WaitForControlledPods(f.ClientSet, "kube-system", "nvidia-gpu-device-plugin", apps.Kind("DaemonSet")) </del> <ins> devicepluginPods, err := framework.WaitForControlledPods(f.ClientSet, "kube-system", "nvidia-gpu-device-plugin", extensionsinternal.Kind("DaemonSet")) </ins> if err == nil { framework.Logf("Adding deviceplugin addon pod.") pods.Items = append(pods.Items, devicepluginPods.Items...)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug We can see all related with test failed. and so on. I think it maybe relate with PR and . What happened: Always fails. What you expected to happen: Pass all.
/cc PTAL. Thanks.
Why did the not pass the test but was still merged?
/priority important-soon /kind e2e-test-failure
/area platform/gce
Looks like the fix is in
is not a blocking / required test (for merge) currently IIRC, kubernetes/kubernetes uses the "submit-queue" which will only pay attention to some tests.
i think this is true, as confirmed by the current state of this PR: it fails the test, but the CI says instead of is there are way to see which tests would cause a ?
off the top of my head the definitive way is this list: but note that is working on moving us to in the nearish future, and every other kubernetes repo besides this one is either not using merge automation or is using , which behaves differently and has seperate config integrated with the rest of test-infra.
thanks for the details! :+1:
Change:
if err := gate.(featuregate.MutableFeatureGate).Set(fmt.Sprintf("%s=%v", f, originalValue)); err != nil { tb.Errorf("error restoring %s=%v: %v", f, originalValue, err) } <ins> for _, cleanup := range cleanups { cleanup() } </ins> } }

Discussion:
PR was reverted by because it (erroneously) relied on OpenAPIV3 feature to be enabled, but would non-deterministically leave the feature disabled after running. I tracked it down to the fact that this test disables all or features in a loop which iterates over a , which are known to have unstable iteration order: When key is processed before key , then would disable before s default value is to be saved. Normally, ignores features that have been explicitly set, so it only affects those which fall back on the value. But this issue does not just affect but any non-GA feature. I suggest the loop in be made to skip the special feature keys such as . /cc /cc The value before every feature gate should be restored after running . This test always fails on my machine (just pasted it into ): No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
Wow, good catch, sorry to make you track down what turned out to be a bug in our test
/sig auth
/area test
/triage accepted
Change:
"time" "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/v1" </ins> "k8s.io/kubernetes/pkg/apis/componentconfig" "k8s.io/kubernetes/pkg/apis/componentconfig/v1alpha1" "k8s.io/kubernetes/pkg/kubelet/qos"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When testing , I found kube-proxy can not record event with following errors. What you expected to happen: No errors How to reproduce it (as minimally and precisely as possible): cc
I am still getting this with the latest build
, thanks for your feedback, I'll check it.
Change:
return storage.NewInternalErrorf("unable to transform key %q: %v", kv.Key, err) } <del> // Check if the request has already timed out before decode object select { case <-ctx.Done(): // parent context is canceled or timed out, no point in continuing return storage.NewTimeoutError(string(kv.Key), "request did not complete within requested timeout") default: } </del> if err := appendListItem(v, data, uint64(kv.ModRevision), opts.Predicate, s.codec, s.versioner, newItemFunc); err != nil { recordDecodeError(s.groupResourceString, string(kv.Key)) return err

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
func (o *setOptions) complete(cmd *cobra.Command) error { endingArgs := cmd.Flags().Args() if len(endingArgs) != 2 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", endingArgs) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", endingArgs) </ins> } o.propertyValue = endingArgs[1]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
EmitDeltaTypeReplaced bool } <del> // NewDeltaFIFOWithOptions returns a Queue which can be used to process changes to // items. See also the comment on DeltaFIFO. func NewDeltaFIFOWithOptions(opts DeltaFIFOOptions) *DeltaFIFO { if opts.KeyFunction == nil { opts.KeyFunction = MetaNamespaceKeyFunc } f := &DeltaFIFO{ items:        map[string]Deltas{}, queue:        []string{}, keyFunc:      opts.KeyFunction, knownObjects: opts.KnownObjects, emitDeltaTypeReplaced: opts.EmitDeltaTypeReplaced, } f.cond.L = &f.lock return f } </del> // DeltaFIFO is like FIFO, but differs in two ways.  One is that the // accumulator associated with a given object's key is not that object // but rather a Deltas, which is a slice of Delta values for that

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: While reviewing for I noticed that introduced a second type of Delta that is specific to DeltaFIFO but did not update the relevant documentation at , which was introduced by concurrent PR . What you expected to happen: I expected the documentation on DeltaFIFO to be current. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
BTW, I think it would be more reader-friendly if the definitions of Deltas and related types were closer to their mentions near the top of the file rather than near the end.
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted </details
Hi, is someone working on this? If no, can I pick it up? Thanks.
: go ahead, and thanks!
Thanks! /assign
Change:
} } <ins> func TestValidatePriorityWithOverFlowWeight(t *testing.T) { policy := api.Policy{Priorities: []api.PriorityPolicy{{Name: "WeightPriority", Weight: api.MaxWeight}}} if ValidatePolicy(policy) == nil { t.Errorf("Expected error about priority weight not being overflown.") } } </ins> func TestValidateExtenderWithNonNegativeWeight(t *testing.T) { extenderPolicy := api.Policy{ExtenderConfigs: []api.ExtenderConfig{{URLPrefix: "http://127.0.0.1:8081/extender", FilterVerb: "filter", Weight: 2}}} errs := ValidatePolicy(extenderPolicy)

Discussion:
Weight is an int (see ). Priority can take the range 1-10. Total priority for a node is sum of weight  priority for each priority function, and the sum is accumulated into an int (see ). So obviously the total priority can overflow if someone sets the weight(s) too high. The weights of all priority functions are compiled in (or specified in config file), so we can check to make sure maximum total priority can't overflow an int (take sum over all priority functions of 10  weight of that priority function, and make sure that's smaller than int(MaxUint 1) which according to StackOverflow is the way to find out what is max int (math package has max Int32, Int64, etc. but not max Int). Note that scheduler extender is OK because although the policy runs in a separate process, the weight is specified in scheduler config file (ExtenderConfig struct) and the priority is bounded 1-10 as usual.
We really should also make "score" be an abstract datatype rather than a raw int that is manipulated directly, so we can do things like make sure it is in the range 1-10 (or 0-10 if that's what we want); today the range is inconistent (we say 1-10, but sometimes use 0; probably we should change it to 0-9..).
I volunteer myself to do this.
I think we can check weight overflow in after we get all PriorityConfig. what do you think about this?
As for "score" I think we can use
Fixed by - closing.
Tim that PR was closed, not merged. I don't think this is fixed yet.
whoops, good catch, just removing milestone then. There was a shift that happened yesterday where a bunch of items suddenly came into the 1.6 query.
do we still want this fixed? I can re-pick this.
AFAIK it's still broken. cc/
Ok, I will open a PR tomorrow.
Change:
EphemeralContainerCommon: v1.EphemeralContainerCommon{ Name:    ecName, Image:   imageutils.GetE2EImage(imageutils.BusyBox), <del> Command: e2epod.GenerateScriptCmd("while true; do sleep 2; echo polo; done"), </del> <ins> Command: e2epod.GenerateScriptCmd("while true; do echo polo; sleep 2; done"), </ins> Stdin:   true, TTY:     true, },

Discussion:
E2eNode Suite.[sig-node] Ephemeral Containers will start an ephemeral container in an existing pod node-kubelet-orphans Unknown, possibly was never green No response KEP: /sig node
Also need to fish this test out of the orphans by adding the label
can you please take a look?
yup, happy to /assign
could you explain this more? This label should exist even though the feature is no longer alpha?
Looks like the tests are still passing in the presubmits It looks like the kubectl invocation is asking for a username?
Moved to node features and now the error message is: kubectl isn't available to the node tests? Hmm..
/triage accepted
/reopen The test is flaking now, can you please take a look?
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
Ah, I think I know what the problem is. Didn't get a chance to look at it today but will get to it soon.
FYI, I spot checked several of the recent failures and so far none of them include the fix commit. Will keep an eye on it.
Yes, thank you. Looks very green now
Change:
RestartPolicy: v1.RestartPolicyNever, Volumes: []v1.Volume{ { <del> Name:         config.Prefix + "-volume", </del> <ins> Name:         volMountName, </ins> VolumeSource: volume, }, },

Discussion:
Failing Job: These tests started flaking recently (they were consistently green for a long time): Mounted volume expand[Slow] Should verify mounted devices can be resized Volume expand [Slow] Verify if editing PVC allows resize Subpath [Volume type: gcePDPVC] should support restarting containers using file as subpath [Slow] Subpath [Volume type: gcePDPVC] should fail for new directories when readOnly specified in the volumeSource Subpath [Volume type: gcePDPVC] should fail if subpath with backstepping is outside the volume [Slow] Volumes PD should be mountable with ext4 Affected runs: https://k8s- https://k8s- https://k8s- /kind bug /sig storage /priority important-soon /milestone v1.12 /cc - Could you PTAL or delegate? Thanks.
Volume expansion tests have been fixed by
/assign can you investigate the remaining failures?
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.12 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening this issue, as a bunch of storage-related e2es started flaking in our large-scale jobs recently: https://k8s- https://k8s- /reopen
I think the latest failures are caused by gce API rate limiting: /assign
It seems to only be failing on scalability test suites. I wonder if it's due to some different cidr configuration
/sig scalability
/kind failing-test
/status approved-for-milestone Friendly ping. This is affecting release-blocking scalability job.
hey what needs to be done here? by whom?
Could you comment on what needs to be done here and by whom?
can you guys take a look at the API quota issue?

This is happening consistently in the scale test environment
as Code Freeze is today, this needs to be of priority . Please triage! cc
It looks like the latest run on 9/1 has passed.
Marking closed as the fixes have been merged and the test runs are now passing /close
Closing this issue. <detailsIn response to : Marking closed as the fixes have been merged and the test runs are now passing /close 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:
lb.updateAffinityMap(svcPort, newEndpoints) // OnUpdate can be called without NewService being called externally. // To be safe we will call it here.  A new service will only be created <del> // if one does not already exist. state = lb.newServiceInternal(svcPort, api.ServiceAffinityNone, 0) </del> <ins> // if one does not already exist.  The affinity will be updated // later, once NewService is called. state = lb.newServiceInternal(svcPort, api.ServiceAffinity(""), 0) </ins> state.endpoints = slice.ShuffleStrings(newEndpoints) // Reset the round-robin index.

Discussion:
!topic/google-containers/pjx13NWEFcg The bug seems to be in kube-proxy.
Change:
Image: busyboxImage, SecurityContext: &v1.SecurityContext{ Capabilities: &v1.Capabilities{ <del> Add: []v1.Capability{"CAP_NET_RAW"}, </del> <ins> Add: []v1.Capability{"NET_RAW"}, </ins> }, }, Command: getRestartingContainerCommand("/test-empty-dir-mnt", 0, numRestarts, "echo 'some bytes' >/outside_the_volume.txt; ping -c 1 google.com; echo 'hello world' >> /test-empty-dir-mnt/file;"),

Discussion:
Which jobs are failing: ci-cri-containerd-node-e2e Which test(s) are failing: Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api Since when has it been failing: 2020 10-12 09:04 PDT Since Testgrid link: Reason for failure: Capability set incorrectly. CAPNETRAW should be NETRAW. I1013 18:39:19.058] Oct 13 18:10:51.403: INFO: At 2020-10-13 18:09:34 +0000 UTC - event for stats-busybox-0: {kubelet tmp-node-e2e--cos-81--1210-0} Failed: Error: failed to create containerd task: OCI runtime create failed: starting container process caused: unknown capability "CAPCAPNET_RAW": unknown Anything else we need to know: I have no idea where this is documented. It's a best guess.
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
it's a node_e2e test so /sig node
Seems like there's some dispute on who is doing the correct thing.
I would like to have a try.
please see discussion in
Change:
(disk.Vhd != nil && disk.Vhd.URI != nil && diskURI != "" && *disk.Vhd.URI == diskURI) || (disk.ManagedDisk != nil && diskURI != "" && *disk.ManagedDisk.ID == diskURI) { // found the disk <del> glog.V(4).Infof("azureDisk - detach disk: name %q uri %q", diskName, diskURI) </del> <ins> glog.V(2).Infof("azureDisk - detach disk: name %q uri %q", diskName, diskURI) </ins> disks = append(disks[:i], disks[i+1:]...) bFoundDisk = true break

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: retry azure disk attach operation produce too many API calls Not the default value is 6 which means if AttachDisk operation failed, it will retry 6 more times, when disk quota is full on a VM, it produces too many API calls. Retry attach disk behavior is not necessary since it AttachVolume operation fails, k8s attachdetach-controller will retry once a minute until it succeeds. default setting in What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.10, v1.11, v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Change:
gomega.Expect(p.Status.HostIPs).Should(gomega.BeNil()) ginkgo.By("deleting the pod") <del> err := podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(30)) </del> <ins> err := podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(1)) </ins> framework.ExpectNoError(err, "failed to delete pod") }) })

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network 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
/assign
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
) func TestValidateKubeProxyConfiguration(t *testing.T) { <ins> var proxyMode kubeproxyconfig.ProxyMode if runtime.GOOS == "windows" { proxyMode = kubeproxyconfig.ProxyModeKernelspace } else { proxyMode = kubeproxyconfig.ProxyModeIPVS } </ins> successCases := []kubeproxyconfig.KubeProxyConfiguration{ { BindAddress:        "192.168.59.103",

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 /sig network Fix windows UT for proxy mode. Run UTs for in windows, That's because proxy mode "IPVS" is not valid in windows. What happened: What you expected to happen: 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:
/assign