jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func expectTrackedResourceVersion(t *testing.T, tracker *endpointSliceTracker, slice *discovery.EndpointSlice, expectedRV string) { rrv := tracker.relatedResourceVersions(slice) rv, tracked := rrv[slice.Name] if !tracked { t.Fatalf("Expected EndpointSlice %s to be tracked", slice.Name) } if rv != expectedRV { t.Errorf("Expected ResourceVersion of %s to be %s, got %s", slice.Name, expectedRV, rv) } } </ins> func portsAndAddressTypeEqual(slice1, slice2 discovery.EndpointSlice) bool { return apiequality.Semantic.DeepEqual(slice1.Ports, slice2.Ports) && apiequality.Semantic.DeepEqual(slice1.AddressType, slice2.AddressType) }

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: With EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
"//pkg/apis/apps:go_default_library", "//pkg/apis/core:go_default_library", "//pkg/apis/core/validation:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/validation:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library",

Discussion:
/kind bug When deploying a StatefulSet, I included a PVC that specified for the storage capacity. worked perfectly. Running again without making any changes failed with the error: After comparing the server-side yaml to my original, I noticed that it had changed the storage capacity of my PVC to . Changing my original from to allowed me to then successfully run . There is clearly a string representation being used to compare those changes rather than converting to bytes and comparing the numeric representation. How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T22:29:25Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-21T11:34:22Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Azure AKS
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
cc This is probably an issue for any resource.Quantity type.
/sig api-machinery
the issue is use of in statefulset update validation, instead of : explicitly compares quantity objects semantically:
/sig apps
fix is in with picks open to 1.11, 1.10, 1.9
Change:
// won't fail if target label doesn't exist or has been removed. func RemoveLabelOffNode(c *client.Client, nodeName string, labelKey string) { By("removing the label " + labelKey + " off the node " + nodeName) <del> node, err := c.Nodes().Get(nodeName) ExpectNoError(err) if node.Labels == nil || len(node.Labels[labelKey]) == 0 { return </del> <ins> var nodeUpdated *api.Node var node *api.Node var err error for attempt := 0; attempt < UpdateRetries; attempt++ { node, err = c.Nodes().Get(nodeName) ExpectNoError(err) if node.Labels == nil || len(node.Labels[labelKey]) == 0 { return } delete(node.Labels, labelKey) nodeUpdated, err = c.Nodes().Update(node) if err != nil { if !apierrs.IsConflict(err) { ExpectNoError(err) } else { Logf("Conflict when trying to remove a label %v from %v", labelKey, nodeName) } } else { break } time.Sleep(100 * time.Millisecond) </ins> } <del> delete(node.Labels, labelKey) nodeUpdated, err := c.Nodes().Update(node) </del> ExpectNoError(err) By("verifying the node doesn't have the label " + labelKey)

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that NodeSelector is respected if matching [Conformance] {Kubernetes e2e suite}
Change:
if result.err != nil { return nil, err } // Add user container information <del> if dockerContainerName == PodInfraContainerName { </del> <ins> if dockerContainerName == PodInfraContainerName && result.status.State.Running != nil { </ins> // Found network container podStatus.PodIP = result.ip } else {

Discussion:
While fixing the issue on describe events for pod, I found kubelet keep restarting monitoring-heapster-controller container: I retrieved the container log, and found it exit due to database creation failure: I didn't follow up on why influxdb issue. cc/
This happens when InfluxDB service is not up. Heapster retries a few times and then eventually fails. The plan is to avoid failing completely and keep retrying DB creation until it succeeds and bubble up appropriate errors. , Dawn Chen wrote:
Influxdb is running happily without issue on the same node:
Related kube-proxy log:
It looks like a kube-proxy issue.
It looks like there are no endpoints for 'monitoring-influxdb' service. The service itself is active and there is a pod that matches the selector of the service. Here is the 'monitoring-influxdb' service: Influxdb pod that matches the selector for 'monitoring-influxdb' service is running. Here are the endpoints from the apiserver: Wonder why there are no endpoints. cc
I ran into a similar issue where endpoints for monitoring-influxdb was not configured. In my case, the pod state took a long time to move to running (even though the containers on the machine were all running fine). But the endpoints were created as soon as the pod changed to state running.
Probed a bit further and it looks like the kubelet is not populating PodIP.
cc/ Can you take a quick look at this one?
FYI: I am still working on this issue.
Here is a little bit more updates: 1) PodIP is missing on all pods running on that particular node; but pods on other nodes with exact same kubelet do have PodIP associated with. 2) docker inspect shows that every pods on bad node have proper "NetworkMode": 3) docker inspect those pod infra containers, they all have proper IP assigned by docker.
The issue is that the kubelet does not ignore old network containers while computing pod status. Working on a fix.
Nice find :) On Mar 26, 2015 5:50 PM, "Vish Kannan" wrote:
Change:
ctx, cancel := getContextWithCancel() defer cancel() <del> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s)", nodeResourceGroup, nodeName, diskName) </del> <ins> // Invalidate the cache right after updating key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) defer ss.vmssVMCache.Delete(key) klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s)", nodeResourceGroup, nodeName, diskName) </ins> _, err = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, vm) if err != nil { detail := err.Error()

Discussion:
What happened: Azure Disks get randomly mounted in a way that makes them unusable, returning for every disk I/O operation. Affected Pods remain in until someone manually recreates them. What you expected to happen: Azure Disks are consistently usable by Pods inside which they are mounted. How to reproduce it: Create the following StatefulSet. Adjust the replicas and delete the associated Pods () until the problem occurs (i.e. some Pod ends up in ). <details</summary</details</brDefault StorageClass (as created by ACS-Engine): <details</summary</details</brAnything else we need to know?: Nodes were updated from 1.10.4 to 1.10.10, then from 1.10.10 to without a reboot. According to written by the issue is fixed, but I can still observe it quite often. Ref Azure/acs-engine Environment: Kubernetes version: v1.10.10 + Cloud provider or hardware configuration: Azure (westeurope) OS: Ubuntu 16.04.4 LTS Kernel: 4.13.0-1018-azure Install tools: ACS-Engine Others: /kind bug /sig storage /sig azure
In my current test environment: (pod uid is -f23b-11e8-bf38-) on the node Notice the mismatch between the disk referenced by lun0 () and the actual mount (). on the node
After deleting the failing Pod and waiting for its successful recreation: (pod uid is now -f247-11e8-bf38-) on the node This time disks are matching (). on the node
/assign
Change:
func (c *configFactory) invalidatePredicatesForPvUpdate(oldPV, newPV *v1.PersistentVolume) { invalidPredicates := sets.NewString() <ins> // CheckVolumeBinding predicate calls SchedulerVolumeBinder.FindPodVolumes // which will cache PVs in PodBindingCache. When PV got updated, we should // invalidate cache, otherwise PVAssumeCache.Assume will fail with out of sync // error. invalidPredicates.Insert(predicates.CheckVolumeBindingPred) </ins> for k, v := range newPV.Labels { // If PV update modifies the zone/region labels. if isZoneRegionLabel(k) && !reflect.DeepEqual(v, oldPV.Labels[k]) {

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?: /assign What happened: Here's some failures https://k8s- https://k8s-
/assign
More recent failures from https://k8s- https://k8s- https://k8s- https://k8s-
I submitted a PR to fix recent PVAssumeCache.Assume out-of-sync failures:
I wonder if this could be the same issue as
Not sure yet, but there are some other flakes: https://k8s- https://k8s- https://k8s- I'll keep tracking this issue. /reopen
Oh, my mistake, these are failures tests of when PR is not completed. /close
Change:
```console $ kubectl delete namespace limit-example <del> namespaces/limit-example </del> <ins> namespace "limit-example" deleted </ins> $ kubectl get namespaces <del> NAME      LABELS    STATUS default   <none>    Active </del> <ins> NAME      LABELS    STATUS    AGE default   <none>    Active    20m </ins> ``` Summary ---------------------------- Cluster operators that want to restrict the amount of resources a single container or pod may consume <del> are able to define allowable ranges per Kubernetes namespace.  In the absence of any hard limits, the Kubernetes system is able to apply default resource limits if desired in order to constrain the amount of resource a pod consumes on a node. </del> <ins> are able to define allowable ranges per Kubernetes namespace.  In the absence of any explicit assignments, the Kubernetes system is able to apply default resource *limits* and *requests* if desired in order to constrain the amount of resource a pod consumes on a node. </ins>

Discussion:
Since resource QoS is implemented, limitrange also supports request constraint, we can add an example for that.
cc
Change:
Subsystem:         KubeletSubsystem, Name:              ConfigErrorKey, Help:              "This metric is true (1) if the node is experiencing a configuration-related error, false (0) otherwise.", <del> DeprecatedVersion: "1.22", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, )

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 --kubelet failed to start when specifying ,with following error: Try to start kubelet with : Kubernetes version (use ): master branch 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:
/sig node
Submitted PR to fix this issue.
/triage accepted /priority important-soon
Change:
if err != nil { return nil, fmt.Errorf("unable to create proxier: %v", err) } <ins> winkernel.RegisterMetrics() </ins> } else { klog.V(0).InfoS("Using userspace Proxier.") klog.V(0).InfoS("The userspace proxier is now deprecated and will be removed in a future release, please use 'kernelspace' instead")

Discussion:
function on is not being used, and kproxy metrics are not showing on endpoint. See kube-proxy related metrics. Access kube-proxy on and search for kube-proxy specific metrics. No response <detailsKube-proxy build from master </details<details</details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
/milestone v1.24
Change:
func (w *etcdWatcher) sendResult(res *etcd.Response) { switch res.Action { case EtcdCreate, EtcdGet: <ins> // "Get" will only happen in watch 0 case, where we explicitly want ADDED event // for initial state. </ins> w.sendAdd(res) case EtcdSet, EtcdCAS: w.sendModify(res)

Discussion:
Currently, Watch request with resourceVersion=0 results in: returning a single "watch event" for every object existing "now" starts watching from that point This is pretty misleading (e.g. it's different that what we have in etcd, where there is no first step from above). In the v2 api, we should probably eliminate the first stop (or even disallow watch requests with resourceVersion = 0).
/cc
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. 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-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
/remove-lifecycle rotten /lifecycle frozen
What do you mean by v2 API? Are we ever going to have a v2 of the machiery and semantics?
In 2015 I thought it's not ridiculous. I'm not sure I believe in it now. Moreover, with we will actually be taking benefits of semantic like this, so we should close this.
Change:
{% if grains.docker_opts is defined and grains.docker_opts %} DOCKER_OPTS="${DOCKER_OPTS} {{grains.docker_opts}}" {% endif %} <del> DOCKER_OPTS="${DOCKER_OPTS} --bridge cbr0 --iptables=false --ip-masq=false -r=false" </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} --bridge cbr0 --iptables=false --ip-masq=false" </ins> DOCKER_NOFILE=1000000

Discussion:
-r is deprecated in favor of per-container restart policies, which we do not use (yet?). We need a plan to stop setting the -r flag, which will break backwards compat with 1.2
How many back-versions of docker do we want to be compatible with? Current + 2 sounds reasonable to me.
Now that docker 1.3 is our baseline, we should remove this from our configs.
Is this still an issue?
Nope.
We still have -r in our salt template for docker. Fix is in flight.
Change:
ExpectedContent: expectedContent, }, } <del> volume.TestVolumeClient(f, myTestConfig, nil, "", tests) </del> <ins> volume.TestVolumeClientSlow(f, myTestConfig, nil, "", tests) </ins> } myTestCase.TestDynamicProvisioning() }(i)

Discussion:
Which jobs are flaking: gce-cos-master-alpha-features Which test(s) are flaking: [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] provisioning should provision storage with snapshot data source [Feature:VolumeSnapshotDataSource] Testgrid link: Reason for failure: It takes 6 minutes to start a pod with PVC that has been restored from a snapshot, while the test waits only 5 minutes: csi-attacher sidecar says: Perhaps the provisioner should wait until the volume is ready to be used? That may not help with this test timeout, as PVC is provisioned after the Pod is scheduled and the total time could be the same. All this is caused by my PR to test block snapshots, It reworked the tests from using . If snapshots are slow, should all persistent storage tests use / ?
/sig storage
Generally, cutting a snapshot is quick, but uploading can take longer. Does provisioner wait until the snapshot is "ready" before returning success?
cc
(But yes, we should increase the timeout because overall time will still be longer no matter which order we take)
The provisioner does not wait. If snapshot is not readyToUse, creating a volume from it will fail. I'll have to check to see if there's logic to wait in the e2e test. Regarding GCE PD, at restore time, do we need to download the snapshot from object store? If that's the case, it could take a while to download as well.
volume controller should keep trying until snapshot is ready. Looks like attacher tried to attach while disk is not ready. It is strange because I think attach only happen after volume is successfully provisioned.
AFAIK, most cloud providers' snapshot ATM will be uploaded to some remote when taking, and will be downloaded when restoring. GCE PD is one of them.
It's not taking snapshots what slows the test, it's restoring it - returns quickly, but the returned volume is not really usable and attach fails for ~4 minutes until the snapshot is fully restored somewhere in GCE. Now that I am thinking about it, maybe it's better if the driver returns the volume early, so it does not end up orphaned when user deletes corresponding PVC and the provisioner is restarted at the same time.

Anyway, I'll extend the timeout in volume checks. /assign
Which brings me to idea: what about other storage backends? Some of them may take even longer that 10 minutes to restore a snapshot. Or more than 5 minutes to provision an empty volume and run a pod. There should be some configuration of timeouts (timeout multiplier?) for
I opened to investigate from GCE side if this behavior is expected.
Change:
}), }, } <del> systemPriority := int32(2147483647) specs[1].pod.Spec.Priority = &systemPriority </del> <ins> specs[1].pod.Spec.PriorityClassName = highPriorityClassName </ins> runEvictionTest(f, pressureTimeout, expectedNodeCondition, expectedStarvedResource, logDiskMetrics, specs) }) })

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /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
Change:
"k8s.io/apimachinery/pkg/util/sets" utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> "k8s.io/component-base/metrics/legacyregistry" </ins> "k8s.io/component-base/metrics/testutil" "k8s.io/klog/v2" "k8s.io/kubernetes/pkg/features"

Discussion:
When unit tests in are invoked with 1, it fails Unit tests should work for any . This is important for troubleshooting flaking tests. Discovered when I tried to add parallel execution as described in master N/A N/A N/A N/A N/A
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network /area kube-proxy
/cc
Change:
// retrieve VM's ip(s) for _, v := range mvm.Guest.Net { <del> var addressType v1.NodeAddressType </del> if vs.cfg.Network.PublicNetwork == v.Network { <del> addressType = v1.NodeExternalIP } else { addressType = v1.NodeInternalIP } for _, ip := range v.IpAddress { if net.ParseIP(ip).To4() != nil { v1.AddToNodeAddresses(&addrs, v1.NodeAddress{ Type:    addressType, Address: ip, }, ) </del> <ins> for _, ip := range v.IpAddress { if net.ParseIP(ip).To4() != nil { v1.AddToNodeAddresses(&addrs, v1.NodeAddress{ Type:    v1.NodeExternalIP, Address: ip, }, v1.NodeAddress{ Type:    v1.NodeInternalIP, Address: ip, }, ) } </ins> } } }

Discussion:
updated the automatic reloading logic from file watch to polling. This change in behavior needs to be documented [ ] Update the v1.29 release notes to call out this change in behavior (ref: ) to replace references to file watch with polling. /sig auth /triage accepted /assign nilekhc