jiebi/CodeConvo huggingface dataset:
Change:
netutils "k8s.io/utils/net" "github.com/onsi/ginkgo" <del> "github.com/onsi/gomega" </del> ) var kubeProxyE2eImage = imageutils.GetE2EImage(imageutils.Agnhost)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: n/a Which test(s) are failing: "should resolve connection reset issue [Slow]" Since when has it been failing: it never worked Testgrid link: n/a Reason for failure: The image used for the test is using only IPv4 Anything else we need to know: We should: [x] refactor the code to support IPv6 [ ] ~consolidate the image in agnhost~ [x] configure an IPv6 job to test network https://k8s-,%20IPv6,%20master
/assign /sig-network
GitHub didn't allow me to assign the following users: Billy99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /sig-network 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
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
/help wanted
/help wanted /good-first-issue
/remove-good-first-issue the agnhost promotion process is not something easy for new contributors
Hi, I would like to contribute to this.
good, thanks
sorry , I needed to fix it and I took over, thanks for stepping up /assign /remove help-wanted
OK.Yesterday I have refactor the code to support IPv6, but I understand wrong about consolidate the image in agnhost. I'm sorry for not being able to help.
no worries, it was trickier than I thought, thanks again for your help
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
}, fakeCloud: &fake_cloud.FakeCloud{ Machines: []string{"node0"}, <ins> ExtID: map[string]string{ "node0": "ext-node0", "node1": "ext-node1", }, </ins> }, matchRE:              ".*", expectedRequestCount: 1, // List <del> expectedCreated:      []string{}, </del> <ins> expectedNameCreated:  []string{}, expectedExtIDCreated: []string{}, </ins> expectedDeleted:      []string{}, }, {

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).
Change:
location              string storageEndpointSuffix string resourceGroup         string <del> cloud                 *Cloud </del> <ins> // store disk URI when disk is in attaching or detaching process diskAttachDetachMap sync.Map cloud               *Cloud </ins> } // getNodeVMSet gets the VMSet interface based on config.VMType and the real virtual machine type.

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: We found that cloud provider tries to attach a disk, it totally costs 121s in the end one minute(disk still in being detaching state), azure cloud provider tries to delete that disk and it succeeded 121s, attach disk operation succeeded and finally azure vm has attached one non-existing disk What you expected to happen: should not delete an azure disk when that disk is being attached How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The difficulty here is when a disk is being attached or detached, the disk state is still "unattached", would be the reason why delete disk at that time would succeed: Azure disk RP would have two options to fix this issue: a new disk state: , disk delete operation when disk is being attached or detached Otherwise on azure provider(client) side, we cannot know whether that disk is being attached or detached since the second delete disk operation is done after 1 min 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
- testname: Jobs, apply changes to status codename: '[sig-apps] Job should apply changes to a job status [Conformance]' description: Attempt to create a running Job which MUST succeed. Attempt to patch <del> the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed </del> <ins> the Job status which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with update which MUST succeed. Attempt to read its status sub-resource which MUST succeed </ins> release: v1.24 file: test/e2e/apps/job.go - testname: Ensure Pods of an Indexed Job get a unique index.

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig apps
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 suspecting as cause
Ack, indeed, because this is the suite for alpha features enabled. We have this fix ready for the test itself: /cc
/cc It flakes in
/retitle [Flaking Test] [Conformance] [sig-apps] Job should apply changes to a job status
It used to fail with errors like After it fails with : [FAILED] patched object should have the applied condition with LastTransitionTime time.Date(2024, time.March, 7, 17, 58, 34, 0, time.UTC), got time.Date(2024, time.March, 7, 17, 58, 33, 0, time.Local) instead In [It] at: @ 03/07/24 17:58:34.109 Here I open the follow up fix: PTAL.
Change:
"Rev": "787624de3eb7bd915c329cba748687a3b22666a6" }, { <ins> "ImportPath": "github.com/grpc-ecosystem/go-grpc-prometheus", "Rev": "2500245aa6110c562d17020fb31a2c133d737799" }, { </ins> "ImportPath": "github.com/hashicorp/golang-lru", "Rev": "a0d98a5f288019575c6d1f4bb1573fef2d1fcdc4" },

Discussion:
/kind feature Can we provide a way to enable etcd clientv3 prometheus metrics at the apiserver side ? The etcd.clientv3 interface is instantiated and it does not enable metrics. In file in coreos/etcd, one can see the to pass to enable metrics. It would be great if the apiserver has a command line parameter, config/environment variable to enable etcd.clientv3 metrics.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
This issue is quite similar to
Yes, this is a good idea, in fact we just released a new version of the package required for this.
/assign
I can do it.
oh, maybe I should use the new features to implement, I will continue to modify it.
are you referring to injecting the registry to use? Yes I would very much appreciate that, even if we (for now) inject the , that will allow us to modify that more easily in the future.
Change:
oldPod := pods[0].(*v1.Pod) newPod := oldPod.DeepCopy() <del> if podAddressChanged(oldPod, newPod) { t.Errorf("Expected address to be unchanged for copied pod") </del> <ins> if podChanged(oldPod, newPod) { t.Errorf("Expected pod to be unchanged for copied pod") </ins> } newPod.Spec.NodeName = "changed" <del> if !podAddressChanged(oldPod, newPod) { t.Errorf("Expected address to be changed for pod with NodeName changed") </del> <ins> if !podChanged(oldPod, newPod) { t.Errorf("Expected pod to be changed for pod with NodeName changed") </ins> } newPod.Spec.NodeName = oldPod.Spec.NodeName newPod.ObjectMeta.ResourceVersion = "changed" <del> if podAddressChanged(oldPod, newPod) { t.Errorf("Expected address to be unchanged for pod with only ResourceVersion changed") </del> <ins> if podChanged(oldPod, newPod) { t.Errorf("Expected pod to be unchanged for pod with only ResourceVersion changed") </ins> } newPod.ObjectMeta.ResourceVersion = oldPod.ObjectMeta.ResourceVersion newPod.Status.PodIP = "1.2.3.1" <del> if !podAddressChanged(oldPod, newPod) { t.Errorf("Expected address to be changed with pod IP address change") </del> <ins> if !podChanged(oldPod, newPod) { t.Errorf("Expected pod to be changed with pod IP address change") </ins> } newPod.Status.PodIP = oldPod.Status.PodIP newPod.ObjectMeta.Name = "wrong-name" <del> if !podAddressChanged(oldPod, newPod) { t.Errorf("Expected address to be changed with pod name change") </del> <ins> if !podChanged(oldPod, newPod) { t.Errorf("Expected pod to be changed with pod name change") </ins> } newPod.ObjectMeta.Name = oldPod.ObjectMeta.Name <ins> saveConditions := oldPod.Status.Conditions oldPod.Status.Conditions = nil if !podChanged(oldPod, newPod) { t.Errorf("Expected pod to be changed with pod readiness change") } oldPod.Status.Conditions = saveConditions </ins> } func TestDetermineNeededServiceUpdates(t *testing.T) {

Discussion:
This test has started failing on our e2e test suite, erroring out with "Failed to get endpoints..." https://k8s- https://k8s- Example failures https://k8s- https://k8s- cc cc
This may be related to our recently-merged endpoints change in . I'll look into it.
I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign
GitHub didn't allow me to assign the following users: joelsmith. Note that only can be assigned. <detailsIn response to : I verified that the flakiness introduced was a result of . A fix in should be merging soon. /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
Change:
return nil }, }, <ins> { // delete success(?) - volume has deletion timestamp before doDelete() starts "8-13 - volume is has deletion timestamp and is not processed", withVolumeDeletionTimestamp(newVolumeArray("volume8-13", "1Gi", "uid8-13", "claim8-13", v1.VolumeBound, v1.PersistentVolumeReclaimDelete, classEmpty)), withVolumeDeletionTimestamp(newVolumeArray("volume8-13", "1Gi", "uid8-13", "claim8-13", v1.VolumeReleased, v1.PersistentVolumeReclaimDelete, classEmpty)), noclaims, noclaims, noevents, noerrors, // We don't need to do anything in test function because deletion will be noticed automatically and synced. // Attempting to use testSyncVolume here will cause an error because of race condition between manually // calling testSyncVolume and volume loop running. func(ctrl *PersistentVolumeController, reactor *pvtesting.VolumeReactor, test controllerTest) error { return nil }, }, </ins> } for _, test := range tests {

Discussion:
PV controller appears to be processing same object multiple times for same PVC delete event. The reason is mainly because when a PVC is deleted and PV is synced(either because of an event or because of resync), then each update to PV object causes another event which gets processed until PV object is removed from informer/store and really marked as deleted. This results in multiple delete requests being sent to storage provider for same volume. For example - In above gist you can see that volume deletion is being done more than once for pv - /sig storage cc
It looks like this is to some extent by design because events are pulled from workqueue by one goroutine and then do some proccessing and then put into another goroutine via nestedpendingoperations thingy. The problem is, this is inherently "racy" because first goroutine might be pulling events that were triggered by second goroutine and hence causing processing of events that are still in-progress. I take we can't use workqueues with a fixed number of workers because that would kinda limit number of PVs we can provision concurrently, but can we put the item pulled from queue directly into nested_pendingoperations so as we don't have this weird race condition?
Change:
for _, initDriver := range testDrivers { curDriver := initDriver(config) <ins> curConfig := curDriver.GetDriverInfo().Config </ins> Context(testsuites.GetDriverNameWithFeatureTags(curDriver), func() { <del> driver := curDriver </del> BeforeEach(func() { <ins> // Reset config. The driver might have modified its copy // in a previous test. curDriver.GetDriverInfo().Config = curConfig </ins> // setupDriver <del> driver.CreateDriver() </del> <ins> curDriver.CreateDriver() </ins> }) AfterEach(func() { // Cleanup driver <del> driver.CleanupDriver() </del> <ins> curDriver.CleanupDriver() </ins> }) <del> testsuites.RunTestSuite(f, driver, testSuites, intreeTunePattern) </del> <ins> testsuites.RunTestSuite(f, curDriver, testSuites, intreeTunePattern) </ins> }) } })

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce/gke multizone/regional jobs Which test(s) are failing: Only PD tests Since when has it been failing: Around 12/21 with the 16:49 run Testgrid link: https://k8s- Reason for failure: TBD Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
The runs started flaking after merged. cc Here's one failing run: Pod pod-subpath-test-gcepd-dynamicpv-pfsm failed to schedule because of conflicting node selectors: We shouldn't need to set the node selector for PD tests using PVs.
The PR broke the subpath test because the modification to the config struct embedded in the driver info now persists across tests: A quick fix would be to reset that field in CreateDriver. The long-term fix is the change discussed in My preference is to do the quick fix now, then either merge or close PRs in this order: (needs a decision about logging of tests that aren't getting defined, see ) a future PR for What I'd like to avoid is having to rebase PR on top of the long-term solution for issue - that'll be lots of code conflicts.
/assign PR is here: PR
Change:
spec: containers: - name: kubedns <del> image: gcr.io/google_containers/kubedns-{{ arch }}:1.6 </del> <ins> image: gcr.io/google_containers/kubedns-{{ arch }}:1.7 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in

Discussion:
Now that merged, we need to build a new kube-dns release.
I just put in a PR yesterday to fix the missing changelog entry for kube-dns:1.6
Change:
glog.V(3).Infof("Attempting to schedule: %+v", pod) start := time.Now() <del> defer func() { metrics.E2eSchedulingLatency.Observe(metrics.SinceInMicroseconds(start)) }() </del> dest, err := s.config.Algorithm.Schedule(pod, s.config.NodeLister) <del> metrics.SchedulingAlgorithmLatency.Observe(metrics.SinceInMicroseconds(start)) </del> if err != nil { glog.V(1).Infof("Failed to schedule: %+v", pod) s.config.Recorder.Eventf(pod, api.EventTypeWarning, "FailedScheduling", "%v", err) s.config.Error(pod, err) return } <ins> metrics.SchedulingAlgorithmLatency.Observe(metrics.SinceInMicroseconds(start)) </ins> b := &api.Binding{ ObjectMeta: api.ObjectMeta{Namespace: pod.Namespace, Name: pod.Name}, Target: api.ObjectReference{

Discussion:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.
Change:
updated.ObjectMeta.Finalizers = append(updated.ObjectMeta.Finalizers, servicehelper.LoadBalancerCleanupFinalizer) klog.V(2).Infof("Adding finalizer to service %s/%s", updated.Namespace, updated.Name) <del> // TODO(87447) use PatchService from k8s.io/cloud-provider/service/helpers _, err := patch(s.kubeClient.CoreV1(), service, updated) </del> <ins> _, err := servicehelper.PatchService(s.kubeClient.CoreV1(), service, updated) </ins> return err }

Discussion:
PR service patch methods to Once there is a release with that PR included, the code in service-controller and legacy-cloud-providers/gce can be updated to use those. /area platform/gce /assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
Created a PR to use these new functions in Service-controllers.
Change:
fuzz "github.com/google/gofuzz" "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" apidiscoveryv2 "k8s.io/api/apidiscovery/v2" apidiscoveryv2beta1 "k8s.io/api/apidiscovery/v2beta1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
Seeing data race flakes in unit tests: Appears to have just been in /sig api-machinery /priority critical-urgent /assign /cc
This code is mutating the package-level schemebuilder: I think it should be adding the conversions to the local scheme instead:
Fixed in (found several instances)
/triage accepted
Change:
// /api/{version}/* // /api/{version}/* func (r *APIRequestInfoResolver) GetAPIRequestInfo(req *http.Request) (APIRequestInfo, error) { <del> requestInfo := APIRequestInfo{} </del> <ins> requestInfo := APIRequestInfo{ Raw: splitPath(req.URL.Path), } </ins> <del> currentParts := splitPath(req.URL.Path) </del> <ins> currentParts := requestInfo.Raw </ins> if len(currentParts) < 1 { return requestInfo, fmt.Errorf("Unable to determine kind and namespace from an empty URL path") }

Discussion:
The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.
Change:
bkpPortal := b.Portals <del> // create new iface and copy parameters from pre-configured iface to the created iface </del> <ins> // If the initiator name was set, the iface isn't created yet, // so create it and copy parameters from the pre-configured one </ins> if b.InitiatorName != "" { <del> // new iface name is <target portal>:<volume name> newIface := bkpPortal[0] + ":" + b.VolName err = cloneIface(b, newIface) if err != nil { klog.Errorf("iscsi: failed to clone iface: %s error: %v", b.Iface, err) </del> <ins> if err = cloneIface(b); err != nil { klog.Errorf("iscsi: failed to clone iface: %s error: %v", b.InitIface, err) </ins> return "", err } <del> // update iface name b.Iface = newIface </del> } // Lock the target while we login to avoid races between 2 volumes that share the same

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign