jiebi/CodeConvo huggingface dataset:
Code change:
"description": "Endpoint represents a single logical "backend" implementing a service.", "properties": { "addresses": { <del> "description": "addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100.", </del> <ins> "description": "addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100. These are all assumed to be fungible and clients may choose to only use the first element. Refer to: https://issue.k8s.io/106267", </ins> "items": { "default": "", "type": "string"

Related discussion:
text: Taking only into consideration the first endpoint which is in the same zone of the node or has no zone dependency and is ready for serving. & Would it make sense to reopen this issue?
I don't follow entirely what you are suggesting, can you elaborate?
kube-proxy should understand which zone a node is in and prefer endpoints in the same zone.
but that is unrelated to this issue, topology is considered See KEPs related, topology-aware-routing was replaced by topology-aware-hints
thank you for clarifying. It seems ambiguous to me to have a zone attribute and a hint attribute. I fail to implement the hinting on a service in v1.23.8, but this is urelated to this issue.
heh, don't worry, this topic is complex and we went through different solutions, you have more historical context on the KEPs I linked above and this thread in the mailing list
Code change:
// on port 443 // If the Service is nil, that means the handling for the API groupversion is handled locally on this server. // The call will simply delegate to the normal handler chain to be fulfilled. <ins> // +optional </ins> Service *ServiceReference // Group is the API group name this server hosts Group string

Related discussion:
text: /sig api-machinery /kind bug /cc this makes any updates on a "Local" apiservice failing by kubectl (unless you disable the client-side validation). a quick repro: (edit whatever a local apiservice) a label "foo: bar" will fail on the schema validation # "" was not valid: # * : Invalid value: "The edited file failed validation": ValidationError(): missing required field "service" in client-side v1.15.0 server-side v1.15.2 referencing the published openapi v2 for apiservice#spec below:
/label help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted 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
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 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
I can on this if no one else is currently working on it.
sure, feel free to tag me to request reviewing..
awesome, I will /assign
are you still working on this one?
Code change:
<ins> /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package kubelet import ( "testing" "time" "github.com/golang/groupcache/lru" ) func TestTimeCache(t *testing.T) { cache := &timeCache{cache: lru.New(2)} if a, ok := cache.Get("123"); ok { t.Errorf("expected cache miss, got %v, %v", a, ok) } now := time.Now() soon := now.Add(time.Minute) cache.Add("now", now) cache.Add("soon", soon) if a, ok := cache.Get("now"); !ok || !a.Equal(now) { t.Errorf("expected cache hit matching %v, got %v, %v", now, a, ok) } if a, ok := cache.Get("soon"); !ok || !a.Equal(soon) { t.Errorf("expected cache hit matching %v, got %v, %v", soon, a, ok) } then := now.Add(-time.Minute) cache.Add("then", then) if a, ok := cache.Get("now"); ok { t.Errorf("expected cache miss from oldest evicted value, got %v, %v", a, ok) } if a, ok := cache.Get("soon"); !ok || !a.Equal(soon) { t.Errorf("expected cache hit matching %v, got %v, %v", soon, a, ok) } if a, ok := cache.Get("then"); !ok || !a.Equal(then) { t.Errorf("expected cache hit matching %v, got %v, %v", then, a, ok) } } </ins>

Related discussion:
text: These tests have flaked consistently since merged: in many cases, they are the only failure in a test run: Either the functionality introduced by that PR is not reliable, or the test is faulty. /sig node /priority critical-urgent /assign
/milestone v1.19
/assign
Looks like this is failing ~5% of pull-kubernetes-node-e2e runs
FYI
Looks like there might still be a race somewhere looking at the kubelet logs Success case: Fail case:
Looking at it more, it seems like is unexpectedly empty here Success: Fail:
Stacks of interest I think we might be dealing with a stale If there is a call before the container is to the Pod in the runtime and the is called within the 2 second default cache period, it seems possible that the in the could have no containers.
what do you think of this analysis? If so, any obvious solutions occur to you?
If I'm correct, didn't introduce this; just the e2e test exposed an existing bug in the kubelet.
That all looks correct. I'm taking a look at the proposed solutions
Code change:
func (kl *Kubelet) generateAPIPodStatus(pod *v1.Pod, podStatus *kubecontainer.PodStatus) v1.PodStatus { glog.V(3).Infof("Generating status for %q", format.Pod(pod)) <ins> s := kl.convertStatusToAPIStatus(pod, podStatus) </ins> // check if an internal module has requested the pod is evicted. for _, podSyncHandler := range kl.PodSyncHandlers { if result := podSyncHandler.ShouldEvict(pod); result.Evict { <del> return v1.PodStatus{ Phase:   v1.PodFailed, Reason:  result.Reason, Message: result.Message, } </del> <ins> s.Phase = v1.PodFailed s.Reason = result.Reason s.Message = result.Message return *s </ins> } } <del> s := kl.convertStatusToAPIStatus(pod, podStatus) </del> // Assume info is ready to process spec := &pod.Spec allStatus := append(append([]v1.ContainerStatus{}, s.ContainerStatuses...), s.InitContainerStatuses...)

Related discussion:
text: Was running a pod with an activeDeadlineSeconds on a 1.10 cluster. The pod reached the deadline, but the pod status did not contain the latest state of the pod containers (pod containersStatus was empty). The status only had the following fields: The statuses were there immediately prior to the deadline being reached. This broke API clients that were looking at container status.
Looks like the status is just overwritten here if returns true
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
Code change:
close(stopCh) } <ins> // TestEventSeriesWithEventSinkImplRace verifies that when Events are emitted to // an EventSink consecutively there is no data race.  This test is meant to be // run with the `-race` option. func TestEventSeriesWithEventSinkImplRace(t *testing.T) { kubeClient := fake.NewSimpleClientset() eventSink := &EventSinkImpl{Interface: kubeClient.EventsV1()} eventBroadcaster := NewBroadcaster(eventSink) stopCh := make(chan struct{}) eventBroadcaster.StartRecordingToSink(stopCh) recorder := eventBroadcaster.NewRecorder(scheme.Scheme, "test") recorder.Eventf(&v1.ObjectReference{}, nil, v1.EventTypeNormal, "reason", "action", "", "") recorder.Eventf(&v1.ObjectReference{}, nil, v1.EventTypeNormal, "reason", "action", "", "") err := wait.PollImmediate(100*time.Millisecond, 5*time.Second, func() (done bool, err error) { events, err := kubeClient.EventsV1().Events(metav1.NamespaceDefault).List(context.TODO(), metav1.ListOptions{}) if err != nil { return false, err } if len(events.Items) != 1 { return false, nil } if events.Items[0].Series == nil { return false, nil } return true, nil }) if err != nil { t.Fatal("expected that 2 identical Eventf calls would result in the creation of an Event with a Serie") } } </ins> func validateEvent(messagePrefix string, expectedUpdate bool, actualEvent *eventsv1.Event, expectedEvent *eventsv1.Event, t *testing.T) { recvEvent := *actualEvent

Related discussion:
text: recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== |================== WARNING: DATA RACE Read at 0x00c0001236f0 by goroutine 23: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x72 () +0x4d () +0x98 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Previous write at 0x00c0001236f0 by goroutine 24: () +0x2e4 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Goroutine 23 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 Goroutine 24 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (*eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== </detailsWhat you expected to happen: No data race. How to reproduce it (as minimally and precisely as possible): You can run the following code snippet alongside any data race detector. I personally used . Anything else we need to know?: Environment: v0.25.0
/sig api-machinery
/assign Would you mind taking a look to this one? thanks!
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.
Code change:
close(stopCh) } <ins> // TestEventSeriesWithEventSinkImplRace verifies that when Events are emitted to // an EventSink consecutively there is no data race.  This test is meant to be // run with the `-race` option. func TestEventSeriesWithEventSinkImplRace(t *testing.T) { kubeClient := fake.NewSimpleClientset() eventSink := &EventSinkImpl{Interface: kubeClient.EventsV1()} eventBroadcaster := NewBroadcaster(eventSink) stopCh := make(chan struct{}) eventBroadcaster.StartRecordingToSink(stopCh) recorder := eventBroadcaster.NewRecorder(scheme.Scheme, "test") recorder.Eventf(&v1.ObjectReference{}, nil, v1.EventTypeNormal, "reason", "action", "", "") recorder.Eventf(&v1.ObjectReference{}, nil, v1.EventTypeNormal, "reason", "action", "", "") err := wait.PollImmediate(100*time.Millisecond, 5*time.Second, func() (done bool, err error) { events, err := kubeClient.EventsV1().Events(metav1.NamespaceDefault).List(context.TODO(), metav1.ListOptions{}) if err != nil { return false, err } if len(events.Items) != 1 { return false, nil } if events.Items[0].Series == nil { return false, nil } return true, nil }) if err != nil { t.Fatal("expected that 2 identical Eventf calls would result in the creation of an Event with a Serie") } } </ins> func validateEvent(messagePrefix string, expectedUpdate bool, actualEvent *eventsv1.Event, expectedEvent *eventsv1.Event, t *testing.T) { recvEvent := *actualEvent

Related discussion:
text: This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
A PR is out to fix this issue: /remove-lifecycle stale
Code change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ <del> JumpChain: string(KubeNodePortChain), MatchSet: kubeNodePortSetTCP, </del> <ins> JumpChain: string(KubeNodePortChain), MatchSet: "", </ins> }}, string(KubeNodePortChain): {{ JumpChain: "RETURN", MatchSet: kubeNodePortLocalSetTCP, }, { <del> JumpChain: string(KubeMarkMasqChain), MatchSet: "", </del> <ins> JumpChain: string(KubeMarkMasqChain), MatchSet: kubeNodePortSetTCP, </ins> }}, } checkIptables(t, ipt, epIpt)

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /assign I'll make the pull request tomorrow. What happened: start kube-proxy in ipvs mode, create some NodePort services. Then look at the iptables rules. match-set of KUBE-NODE-PORT-TCP is inadequate to be qualified as NodePort traffic. "--dst-type LOCAL" is needed. What you expected to happen: since we have also KUBE-NODE-PORT-UDP, another way would be like this: How to reproduce it (as minimally and precisely as possible): start kube-proxy in ipvs mode, create some NodePort services. Then look at the iptables rules. Anything else we need to know?: Environment: Kubernetes version (use ): commit Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Linux release 7.2.1511 (Core) Kernel (e.g. ): Linux VM34centos 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
/sig network /area kube-proxy /area ipvs /assign
/cc i remember this bug fixed, that's right?
, Thanks, seems like necessary. But you have any use case that ipvs proxier will have bugs in current mach rules?
It's already fixed by ? Can we close this issue now?
I don't see how fixed this issue. How about this scenario: k8s cluster A uses node port for service A k8s cluster B uses node port for service B pod (or host) in cluster A tries to access node port on k8s cluster B local node port rule matches the traffic and NATs it to the local node port, pod (or host) cannot reach cluster B's node port. Also, the remote node port could be replaced by any non-k8s host that happens to use port .
Then I think can solve this problem.
Code change:
import ( "context" <del> "encoding/json" </del> "fmt" "math" "sync"

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-serial (gce-cos-master-serial) Kubernetes e2e suite.[sig-scheduling] SchedulerPriorities [Serial] Pod should avoid nodes that have avoidPod annotation June 19th 2021 () Testgrid: https://k8s- Prow history: Looks like pods are scheduled where they shouldn't be? : The tests passes in maybe 20% of the builds, but it looks random, so I don't treat it as a flake. At the moment there are also sig-storage tests consistently failing in this job: , They don't look related though. /sig scheduling /kind failing-test
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
/milestone v1.22
try to have a look.
try to have a look.
/cc
This is expected. The feature (which was alpha) is now disabled by default. Users can still enable it by switching to a v1beta1 scheduler component config. Let's remove the test.
Code change:
operator: Exists - key: {{ .MasterTaintKey }} effect: NoSchedule <ins> nodeSelector: beta.kubernetes.io/os: linux </ins> containers: - name: coredns image: {{ .ImageRepository }}/coredns:{{ .Version }}

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In a windows cluster, containers can get scheduled on Windows nodes where they will never work. Warning Failed 54m (x3 over 54m) kubelet, 35934k8s9000 Failed to pull image "coredns/coredns:1.2.2": rpc error: code = Unknown desc = no matching manifest for windows/amd64 in the manifest list entries What you expected to happen: CoreDNS starts and runs on Linux master nodes. How to reproduce it (as minimally and precisely as possible): Build a Windows Cluster. Note: I first encountered this issue when deploying with ACS-Engine: but it occurs to me that it should be mirrored here, so that the relevant node selectors can be included in the canonical add-on directory. /sig Windows
I suppose this is fine if there are always linux nodes in the cluster. I don't know how Kubernetes or docker manifests work for windows, but CoreDNS does build and run on windows: That is not included in the manifest, is it possible to get that working? I guess you would probably also have to change the way the mounted config file is referred to in windows? Or is it this change good enough?
For now, IMO yes. what do you think? I'm assuming, perhaps incorrectly, that not all core k8s components support windows yet. do you know the current state of Windows support for core k8s components? Is CoreDNS the only core component whose image doesnt support windows?
Have not looked into it in detail yet, but one complication would be configuration. AFAIK Windows systems don't have an ... and the default CoreDNS configuration makes specific reference to the file (to get upstream servers).
Yeah, good point. I was thinking about the -conf /etc/coredns/Corefile which I think we pass to coredns IIRC. But is a bigger issue.
While it is possible to run Windows coreDNS pods, this is still undocumented and not officially supported yet. Officially, only kubelet & kube-proxy are in beta on Windows and scheduled to GA with 1.13 (assuming it meets the criteria and community votes of course). I think for the time being it should be fine to limit scheduling to Linux only to avoid pods being stuck but we should design in a way to keep the option open of undoing this in the future. what do you think?
Code change:
// namespace used for all tests, do not change this const testNamespace = "dryrunnamespace" <ins> func DryRunCreateWithGenerateNameTest(t *testing.T, rsc dynamic.ResourceInterface, obj *unstructured.Unstructured, gvResource schema.GroupVersionResource) { // special resources with dots in the name cannot use generateName if strings.Contains(obj.GetName(), ".") { return } // Create a new object with generateName to ensure we don't taint the original object gnObj := obj.DeepCopy() gnObj.SetGenerateName(obj.GetName() + "-") gnObj.SetName("") DryRunCreateTest(t, rsc, gnObj, gvResource) } </ins> func DryRunCreateTest(t *testing.T, rsc dynamic.ResourceInterface, obj *unstructured.Unstructured, gvResource schema.GroupVersionResource) { createdObj, err := rsc.Create(context.TODO(), obj, metav1.CreateOptions{DryRun: []string{metav1.DryRunAll}}) if err != nil { <del> t.Fatalf("failed to dry-run create stub for %s: %#v", gvResource, err) </del> <ins> t.Fatalf("failed to dry-run create stub for %s: %#v: %v", gvResource, err, obj) </ins> } if obj.GroupVersionKind() != createdObj.GroupVersionKind() { t.Fatalf("created object doesn't have the same gvk as original object: got %v, expected %v", createdObj.GroupVersionKind(), obj.GroupVersionKind()) } <ins> if createdObj.GetUID() != "" { t.Fatalf("created object shouldn't have a uid: %v", createdObj) } if createdObj.GetResourceVersion() != "" { t.Fatalf("created object shouldn't have a resource version: %v", createdObj) } if obj.GetGenerateName() != "" && createdObj.GetName() != "" { t.Fatalf("created object's name should be an empty string if using GenerateName: %v", createdObj) } </ins> <del> if _, err := rsc.Get(context.TODO(), obj.GetName(), metav1.GetOptions{}); !apierrors.IsNotFound(err) { t.Fatalf("object shouldn't exist: %v", err) </del> <ins> // we won't have a generated name here, so we won't check for this case if obj.GetGenerateName() == "" { if _, err := rsc.Get(context.TODO(), obj.GetName(), metav1.GetOptions{}); !apierrors.IsNotFound(err) { t.Fatalf("object shouldn't exist: %v, %v", obj, err) } </ins> } }

Related discussion:
text: /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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
Code change:
for _, test := range providers { project, zone, instance, err := splitProviderID(test.providerID) if (err != nil) != test.fail { <del> t.Errorf("Expected to failt=%t, with pattern %v", test.fail, test) </del> <ins> t.Errorf("Expected to fail=%t, with pattern %v", test.fail, test) </ins> } if test.fail {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: As part of the initiative for external cloud providers (), we GetZoneByProviderID and GetZoneByNodeName. See for more details. The previous PR did not actually implement those methods for existing cloud providers in . These methods should be implemented by all cloud providers in the future. cc
Could someone add the label and the label for this issue please?
/sig cluster-lifecycle
/area cloudprovider
/assign wlan0
cc We need the following label - help-wanted and add it to the 1.8(?) milestone cc to implement it for their respective clouds.
I'll try to have a look by the end of the week.
Ok, I will take care of the Rackspace and OpenStack.
Thank you !
- Is there any listing where to see the already implemented cloud provider ?
No providers have this yet. Current PRs: Openstack: Rackspace: Please contribute if you have something ready :)
Sorry for the delay guys :)
Have you implemented them for gce?
Intending to work on it tonight, but if you have something I can work on azure
Yes, I have prepared for GCE.
Azure .
Cool, than you all! Any other providers we should implement this for in time for v1.8?
I'll take a look tomorrow to see if there's something left
Let's see which providers are left before closing this...
- I guess this one should be closed ?
If you say that all providers have this now, thanks, great!
Code change:
<del> // +build !linux </del> <ins> // +build windows </ins> /* Copyright 2014 Google Inc. All rights reserved.

Related discussion:
text: This whole set of tests (if it can't be run) should be omitted from the test execution, otherwise folks running on Mac can't verify everything else is clean in a sane fashion. Passive aggressive assign to Tim, I may get around to fixing this before he does.
Last I checked Travis + Go didn't work. We should check again, and enable OS X builds in Travis if it's possible.
You could argue that if the unsupported mount () is being called in a test, there is a problem anyway - it has to run as root. Will investigate. On Jan 25, 2015 9:09 AM, "Brendan Burns" wrote:
Without a Mac to test on, I feel like this would be better fixed by someone who uses Mac... Probably: just rename to I just discovered "implicit build constraints", sigh. Go is crossing from user-friendly to sort of absurd, IMO.