jiebi/CodeConvo huggingface dataset:
Code change:
componentbaseconfig "k8s.io/component-base/config" "k8s.io/component-base/configz" "k8s.io/component-base/logs" <ins> metricsfeatures "k8s.io/component-base/metrics/features" </ins> "k8s.io/component-base/metrics/legacyregistry" <ins> "k8s.io/component-base/metrics/prometheus/slis" </ins> "k8s.io/component-base/version" "k8s.io/component-base/version/verflag" "k8s.io/klog/v2"

Related discussion:
text: As per, , wire up metrics/slis for kube-proxy
/assign
/sig network /sig instrumentation
This sounds OK, but we need to translate it into real work-to-do - volunteers? /triage accepted
is tackling this one :)
Code change:
if err != nil { return nil, err } <ins> ams, err := getVolumeAccessModes(spec) if err != nil { return nil, err } </ins> return &rbdMounter{ rbd:          newRBD(podUID, spec.Name(), img, pool, ro, plugin, manager),

Related discussion:
text: <!-- 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?: What happened: When use ceph as storageclass, i set accessModes: ReadOnlyMany, and create pods using the claim, only one pod would be running and the others on different nodes would get stuck on ContainerCreating. But if the pods are all on same node, it works fine. What you expected to happen: Pods on different nodes can mount ceph rbd volume. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): 3.10.0-327.18.2.el7.x86_64 Kernel (e.g. ): CentOS Linux release 7.2.1511 (Core) Install tools: kubeadm Others:
/sig storage
/assign
, how would this work? For example, how do you put the initial contents of the RBD volume on it if it is in the ReadOnlyMany access mode? How would you use this feature? As a cheap way of sharing files across a Kubernetes cluster? I'm just interested. -ben england
Do we really want to support ? I have the same questions as mentioned above. If we set the PVC AccessMode to , then the field in will need to be set true ? If so, for the first time, in , we will mount the device without formatting, is that intended ? We need to format the device manually before we use it ? /cc FYI: also there is an issue related to this:
We have this same problem for GCE PD, which supports ReadOnlyMany. You need to mount the volume first as RWO, in order to format the filesystem and populate it with data (mounting a read only volume with no data on it seems pointless). Then you have to fully unmount/detach it, and then you can deploy pods using it as ROX. Basically, you can dynamically provision it in RWO to format + populate data. But afterwards, you need to manually create a different PV/PVC for ROX
continuation
Code change:
func isKeyNotFoundError(err error) bool { statusErr, _ := err.(*errors.StatusError) <del> // At the moment the server is returning 500 instead of a more specific // error. When changing this remember that it should be backward compatible // with old api servers that may be still returning 500. if statusErr != nil && statusErr.Status().Code == 500 { </del> <ins> if statusErr != nil && statusErr.Status().Code == http.StatusNotFound { </ins> return true } return false }

Related discussion:
text: I keep seeing these server rejected event errors every now and then. My guess is it is trying to update an event that was expired in etcd. However I don't expect an error, since there is specific logic in to handle that use case. Any ideas why this may happening? I am using kubernetes 1.2. Here is an example, from a host getting to a cluster:
Found the problem - the recordEvent logic in was expecting the wrong status code. I've submitted a PR for it. This could be reproduced by: 1 - Update load balancers by remove a node, then adding it back 2 - Remove all events manually from etcd for that namespace 3 - Remove node and add it back again - this results in server rejected event error
Code change:
} } <ins> func TestLBSecurityGroupsAnnotation(t *testing.T) { awsServices := newMockedFakeAWSServices(TestClusterId) c, _ := newAWSCloud(CloudConfig{}, awsServices) sg1 := map[string]string{ServiceAnnotationLoadBalancerSecurityGroups: "sg-000001"} sg2 := map[string]string{ServiceAnnotationLoadBalancerSecurityGroups: "sg-000002"} sg3 := map[string]string{ServiceAnnotationLoadBalancerSecurityGroups: "sg-000001, sg-000002"} tests := []struct { name string annotations map[string]string expectedSGs []string }{ {"SG specified", sg1, []string{sg1[ServiceAnnotationLoadBalancerSecurityGroups]}}, {"Multiple SGs specified", sg3, []string{sg1[ServiceAnnotationLoadBalancerSecurityGroups], sg2[ServiceAnnotationLoadBalancerSecurityGroups]}}, } awsServices.ec2.(*MockedFakeEC2).expectDescribeSecurityGroups(TestClusterId, "k8s-elb-aid", "cluster.test") for _, test := range tests { t.Run(test.name, func(t *testing.T) { serviceName := types.NamespacedName{Namespace: "default", Name: "myservice"} sgList, err := c.buildELBSecurityGroupList(serviceName, "aid", test.annotations) assert.NoError(t, err, "buildELBSecurityGroupList failed") assert.True(t, sets.NewString(test.expectedSGs...).Equal(sets.NewString(sgList...)), "Security Groups expected=%q , returned=%q", test.expectedSGs, sgList) }) } } </ins> // Test that we can add a load balancer tag func TestAddLoadBalancerTags(t *testing.T) { loadBalancerName := "test-elb"

Related discussion:
text: The situation pre-1.13.0 is somewhat surprising because explicitly setting to an empty array like so: has no effect, and the Security Group Ingress is still .
Code change:
// second in a bucket, and pop up them once at the timeout. To be more specific, // if you set fire time at X, you can get the bookmark within (X-1,X+1) period. type watcherBookmarkTimeBuckets struct { <del> lock            sync.Mutex watchersBuckets map[int64][]*cacheWatcher startBucketID   int64 clock           clock.Clock </del> <ins> lock              sync.Mutex watchersBuckets   map[int64][]*cacheWatcher startBucketID     int64 clock             clock.Clock bookmarkFrequency time.Duration </ins> } <del> func newTimeBucketWatchers(clock clock.Clock) *watcherBookmarkTimeBuckets { </del> <ins> func newTimeBucketWatchers(clock clock.Clock, bookmarkFrequency time.Duration) *watcherBookmarkTimeBuckets { </ins> return &watcherBookmarkTimeBuckets{ <del> watchersBuckets: make(map[int64][]*cacheWatcher), startBucketID:   clock.Now().Unix(), clock:           clock, </del> <ins> watchersBuckets:   make(map[int64][]*cacheWatcher), startBucketID:     clock.Now().Unix(), clock:             clock, bookmarkFrequency: bookmarkFrequency, </ins> } } // adds a watcher to the bucket, if the deadline is before the start, it will be // added to the first one. func (t *watcherBookmarkTimeBuckets) addWatcher(w *cacheWatcher) bool { <del> nextTime, ok := w.nextBookmarkTime(t.clock.Now()) </del> <ins> nextTime, ok := w.nextBookmarkTime(t.clock.Now(), t.bookmarkFrequency) </ins> if !ok { return false }

Related discussion:
text: Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Code change:
apiVersion: extensions/v1beta1 kind: Deployment metadata: <del> name: metrics-server-v0.3.0 </del> <ins> name: metrics-server-v0.3.1 </ins> namespace: kube-system labels: k8s-app: metrics-server kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> spec: selector: matchLabels: k8s-app: metrics-server <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> template: metadata: name: metrics-server labels: k8s-app: metrics-server <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> annotations: scheduler.alpha.kubernetes.io/critical-pod: '' seccomp.security.alpha.kubernetes.io/pod: 'docker/default'

Related discussion:
text: This started after was merged. The HPA test started being very flaky since then: https://k8s- The HPA test in containerd e2e become even more flaky since then with the same failure pattern: https://k8s-
I think this is probably /priority critical-urgent Release team hasn't looked close enough at this issue as we've been trying to clear other issues in front of it. If we crack those and this is unrelated root cause, then this one's going to be a release blocker.
It's going to be supremely hard to debug this unless we have logs from metrics-server and/or snapshots of the HPA over time. I'm trying to reproduce on a local cluster, but so far, the test passes consistently. did you manage to reproduce locally?
is there any way to grab logs of pods from a testing cluster?
you probably want to save it as part of the artifacts?
yeah, what's the process for that?
somewhere along
See for an attempt at debugging this.
can we provide the data is looking for? we're seeing this quite often.
ack, more logs would be helpful. Currently trying to get usable logs off the CI with the aforementioned PR, but I keep making minor mistakes in the log collection script :-/. It seems to repro every few runs though, so with any luck I'll see it again soon.
Got a WIP fix up: Need to do one more tweak before merge.
Re-running tests with the above PR, if they succeed I'll merge and get someone to do a build when the people capable of running builds are on next.
status check? I'm worried this is a 1.12 blocker and need to make a call by end of day today regarding delaying the release.
According to our testing, metrics-server 0.3.1 seems to have fixed it - thank you
Code change:
}) } <ins> testDone := make(chan struct{}) defer close(testDone) </ins> ts := httptest.NewServer( withDeadline( WithTimeoutForNonLongRunningRequests(

Related discussion:
text: Similar to and easily reproducible. The handler occasionally completes and sends a response before timing out. /kind failing-test /kind flake /sig api-machinery
/assign
/assign Thank you very much for fixing these tests.
/triage accepted
Code change:
Count:            1, LastObservedTime: metav1.MicroTime{Time: clock.Now()}, } <del> return isomorphicEvent </del> <ins> // Make a copy of the Event to make sure that recording it // doesn't mess with the object stored in cache. return isomorphicEvent.DeepCopy() </ins> } e.eventCache[eventKey] = eventCopy <del> return eventCopy </del> <ins> // Make a copy of the Event to make sure that recording it doesn't // mess with the object stored in cache. return eventCopy.DeepCopy() </ins> }() if evToRecord != nil { <del> recordedEvent := e.attemptRecording(evToRecord) if recordedEvent != nil { recordedEventKey := getKey(recordedEvent) e.mu.Lock() defer e.mu.Unlock() e.eventCache[recordedEventKey] = recordedEvent } </del> <ins> // TODO: Add a metric counting the number of recording attempts e.attemptRecording(evToRecord) // We don't want the new recorded Event to be reflected in the // client's cache because server-side mutations could mess with the // aggregation mechanism used by the client. </ins> } }() }

Related discussion:
text: <!-- 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: I wrote a test creating multiple isomorphic Events with an "". and stumbled upon a data race. The data race happens in the function. It seems that the Event Series field can be read and written at the same time by two different goroutines. . This seems to happen in only one scenario: (1) a singleton Event is created (2) an isomorphic Event is created (1) lock addition to cache (2) wait for the lock to be released (1) unlock (2) lock + the Series (1) the freshly created Series (1) singleton Event is now considered as a series That being said, this seems to lead to some data inconsistencies as the singleton Event would be created with an unexpected Series. <details<summaryData race</summary|================== WARNING: DATA RACE Write at 0x00c0001237a0 by goroutine 23: (eventBroadcasterImpl).recordToSink.func1.1() +0x536 (eventBroadcasterImpl).recordToSink.func1() +0x84 Previous read at 0x00c0001237a0 by goroutine 24: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x56 (Event).DeepCopyObject() +0x33 () +0xe8 (CreateActionImpl).DeepCopy() <autogenerated:1 +0xb7 (Fake).Invokes() +0x103 (FakeEvents).Create() +0x214 (EventSinkImpl).Create() +0x195 () +0x32c (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).
Code change:
Count:            1, LastObservedTime: metav1.MicroTime{Time: clock.Now()}, } <del> return isomorphicEvent </del> <ins> // Make a copy of the Event to make sure that recording it // doesn't mess with the object stored in cache. return isomorphicEvent.DeepCopy() </ins> } e.eventCache[eventKey] = eventCopy <del> return eventCopy </del> <ins> // Make a copy of the Event to make sure that recording it doesn't // mess with the object stored in cache. return eventCopy.DeepCopy() </ins> }() if evToRecord != nil { <del> recordedEvent := e.attemptRecording(evToRecord) if recordedEvent != nil { recordedEventKey := getKey(recordedEvent) e.mu.Lock() defer e.mu.Unlock() e.eventCache[recordedEventKey] = recordedEvent } </del> <ins> // TODO: Add a metric counting the number of recording attempts e.attemptRecording(evToRecord) // We don't want the new recorded Event to be reflected in the // client's cache because server-side mutations could mess with the // aggregation mechanism used by the client. </ins> } }() }

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:
Count:            1, LastObservedTime: metav1.MicroTime{Time: clock.Now()}, } <del> return isomorphicEvent </del> <ins> // Make a copy of the Event to make sure that recording it // doesn't mess with the object stored in cache. return isomorphicEvent.DeepCopy() </ins> } e.eventCache[eventKey] = eventCopy <del> return eventCopy </del> <ins> // Make a copy of the Event to make sure that recording it doesn't // mess with the object stored in cache. return eventCopy.DeepCopy() </ins> }() if evToRecord != nil { <del> recordedEvent := e.attemptRecording(evToRecord) if recordedEvent != nil { recordedEventKey := getKey(recordedEvent) e.mu.Lock() defer e.mu.Unlock() e.eventCache[recordedEventKey] = recordedEvent } </del> <ins> // TODO: Add a metric counting the number of recording attempts e.attemptRecording(evToRecord) // We don't want the new recorded Event to be reflected in the // client's cache because server-side mutations could mess with the // aggregation mechanism used by the client. </ins> } }() }

Related discussion:
text: If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
We might also want to look into that again for /reopen /assign /unassign
/remove-lifecycle rotten
Reopened this issue. <detailsIn response to : We might also want to look into that again for /unassign 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
/cc
/cc
I was able to reproduce this issue with client-go v0.25.0. I updated the reproducer to be compatible with the latest version of the client and attached the data race trace.
are you gong to submit a fix for this one? thanks. /triage accepted
Yes, I am planning to submit a fix for this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
Count:            1, LastObservedTime: metav1.MicroTime{Time: clock.Now()}, } <del> return isomorphicEvent </del> <ins> // Make a copy of the Event to make sure that recording it // doesn't mess with the object stored in cache. return isomorphicEvent.DeepCopy() </ins> } e.eventCache[eventKey] = eventCopy <del> return eventCopy </del> <ins> // Make a copy of the Event to make sure that recording it doesn't // mess with the object stored in cache. return eventCopy.DeepCopy() </ins> }() if evToRecord != nil { <del> recordedEvent := e.attemptRecording(evToRecord) if recordedEvent != nil { recordedEventKey := getKey(recordedEvent) e.mu.Lock() defer e.mu.Unlock() e.eventCache[recordedEventKey] = recordedEvent } </del> <ins> // TODO: Add a metric counting the number of recording attempts e.attemptRecording(evToRecord) // We don't want the new recorded Event to be reflected in the // client's cache because server-side mutations could mess with the // aggregation mechanism used by the client. </ins> } }() }

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:
// ValidateKubeletFlags validates Kubelet's configuration flags and returns an error if they are invalid. func ValidateKubeletFlags(f *KubeletFlags) error { unknownLabels := sets.NewString() <del> for k := range f.NodeLabels { </del> <ins> invalidLabelErrs := make(map[string][]string) for k, v := range f.NodeLabels { </ins> if isKubernetesLabel(k) && !kubeletapis.IsKubeletLabel(k) { unknownLabels.Insert(k) } <ins> if errs := validation.IsQualifiedName(k); len(errs) > 0 { invalidLabelErrs[k] = append(invalidLabelErrs[k], errs...) } if errs := validation.IsValidLabelValue(v); len(errs) > 0 { invalidLabelErrs[v] = append(invalidLabelErrs[v], errs...) } </ins> } if len(unknownLabels) > 0 { return fmt.Errorf("unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels: %vn--node-labels in the 'kubernetes.io' namespace must begin with an allowed prefix (%s) or be in the specifically allowed set (%s)", unknownLabels.List(), strings.Join(kubeletapis.KubeletLabelNamespaces(), ", "), strings.Join(kubeletapis.KubeletLabels(), ", ")) } <ins> if len(invalidLabelErrs) > 0 { labelErrs := []string{} for k, v := range invalidLabelErrs { labelErrs = append(labelErrs, fmt.Sprintf("'%s' - %s", k, strings.Join(v, ", "))) } return fmt.Errorf("invalid node labels: %s", strings.Join(labelErrs, "; ")) } </ins> if f.SeccompDefault && !utilfeature.DefaultFeatureGate.Enabled(features.SeccompDefault) { return fmt.Errorf("the SeccompDefault feature gate must be enabled in order to use the --seccomp-default flag")

Related discussion:
text: kubelet won't return error when invalid node labels are passed to flag, and node can't take part in a cluster. kubelet should return errors when invalid node labels are passed. You pass flag to kubelet (value is invalid), node doesn't take part in a cluster. ref. No response <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
this should not be a breaking change as invalid labels make the kubelet unusable anyway. So better not even start the kubelet. /assign since there is a PR already
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. 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]:
Code change:
t.Errorf("Failed to update node in schedulercache:n got: %+v nexpected: %+v", got, expected) } // Check nodeTree after update <del> if cache.nodeTree.NumNodes != 1 || cache.nodeTree.Next() != node.Name { </del> <ins> if cache.nodeTree.NumNodes() != 1 || cache.nodeTree.Next() != node.Name { </ins> t.Errorf("unexpected cache.nodeTree after updating node: %v", node.Name) }

Related discussion:
text: Description: , part of the is exporting a field which allows to modify its value externally. This also means that this field is not thread-safe. Solution: Expose a method that returns this value in a thread-safe way and do not export the field. /kind bug /sig scheduling