jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/kubernetes/pkg/kubelet/util/format" hashutil "k8s.io/kubernetes/pkg/util/hash" "k8s.io/kubernetes/third_party/forked/golang/expansion" <ins> utilsnet "k8s.io/utils/net" </ins> ) // HandlerRunner runs a lifecycle handler for a container.

Discussion:
What happened: I tried to create a deployment with duplicate containerPorts with hostIPs of two different address families. Only the first mapping was provided as input into my CNI plugin chain. Also, a log message from kubelet warning about a duplicate containerPort was created. What you expected to happen: Both mappings to be provided as input into my CNI plugins. No log messages should be created. How to reproduce it (as minimally and precisely as possible): Create this deployment: Then grab kubelet logs on the host e.g: Anything else we need to know?: This issue here provides some context as to how I ran into this issue: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: DigitalOcean, custom setup OS (e.g: ):Kernel (e.g. ):Install tools: None Network plugin and version (if this is a network-related bug): Cilium v1.6.0 and Portmap v0.8.2 Others: N/A I've already identified the problem and will submit a PR which fixes this shortly. /sig network
is this dual-stack only? if so, does the fix for this need to target 1.16?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This applies to dual-stack only yes. I don't know if it should target 1.16, personally I'd like to get this out so I don't have to run a forked version of kubelet.
/assign
I would agree that this should hit v1.16 if possible.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Change:
-o "${tmp_kube_env}"  http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env # Convert the yaml format file into a shell-style file. <del> eval $(python -c ''' </del> <ins> eval $(${PYTHON} -c ''' </ins> import pipes,sys,yaml for k,v in yaml.load(sys.stdin).iteritems(): print("readonly {var}={value}".format(var = k, value = pipes.quote(str(v))))

Discussion:
What happened: Pick an OS image where python is python3 and the cluster will not come up. What you expected to happen: Cluster should come up. How to reproduce it (as minimally and precisely as possible): Switch the default OS image to use an OS which has python3 as the default python. Run cluster/kube- for GCE. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider
/assign
Change:
"type": "integer" }, "fsGroupChangePolicy": { <del> "description": "fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified defaults to "Always".", </del> <ins> "description": "fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified, "Always" is used.", </ins> "type": "string" }, "runAsGroup": {

Discussion:
We need to move this field to beta in 1.20. /sig storage
/triage accepted
According to , is working on a better design on this.
Nope. The current design is the design we are going to use to handle fsgroup. we discussed this at length in sig-storage call.
Is it okay if I make this change?
Change:
} count++ <ins> if len(output) > 0 && !shortOutput { return cmdutil.PrintResourceInfoForCommand(cmd, info, f, out) } </ins> cmdutil.PrintSuccess(mapper, shortOutput, out, info.Mapping.Resource, info.Name, dryRun, "created") return nil }

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR
Change:
// Close the queue. func (f *FIFO) Close() { <del> f.closedLock.Lock() defer f.closedLock.Unlock() </del> <ins> f.lock.Lock() defer f.lock.Unlock() </ins> f.closed = true f.cond.Broadcast() }

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: Race conditions found on 2 usages of sync.Cond in client-go/tools/cache.DeltaFIFO and client-go/tools/watch/eventProcessor. I don't know how harmful they are since the buggy interleaving is hard to trigger. They may lead to goroutine leaks to my understanding. They have similar causes and I put them in one issue here for ease of triage. When and are invoked concurrently on an empty queue, the in may miss the signal from . The is guarded by the for-loop below. It appears that should not be called if the FIFO queue is already closed, hence the check at line 475. However, the check above may race with : Specifically, when the queue is empty and not closed, will reach the . Between the check and , another goroutine can call and the broadcast on will be missed. Consequently, may block indefinintely and miss the broadcast on from . Note that holds while and hold . So can interleave with . Here is a stack trace found by our tool while running . The tool is based on the Go race detector. I did some research and found introduced the bug while trying to fix exactly the issue: "stop controller when the stop channel is closed and the queue is empty". The fix doesn't appear to solve the issue completely. One suggested fix: use in and instead of . This would enforce atomicity between the check and in . This is similar to DeltaFIFO. In between and : Another goroutine can call : This would cause the signal on to be missed by the above , leading to the goroutine being blocked unexpectedly. Stack trace from : One suggested fix: use mutex to protect in . What you expected to happen: No race condition. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): MacOS Kernel (e.g. ): Darwin Install tools: Network plugin and version (if this is a network-related bug): Others: This is my first issue filed.

Please let me know if I can provide further information.
/sig api-machinery
For issue 1, in probably the date race is not uncovered due to Run() being long running. If we use f.lock in f.Close() and f.IsClosed(), closedLock is not needed any more. Since f.lock is taken at the beginning of Pop(), we would need lockless version of IsClosed()
Oh..Right. I didn't see this point. Please ignore my suggested fix for issue 1 then.
/cc
Hi, I reproduced the goroutine leak with this test case. The control loop inside may not exit when is called on an empty queue due to the race condition. Also, I submitted a PR trying to fix it. :smile:
Change:
"fmt" "net/http" "path" <ins> "time" </ins> <del> compute "google.golang.org/api/compute/v1" </del> <ins> "google.golang.org/api/compute/v1" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/klog" <del> "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud" </del> "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud/filter" "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud/meta" cloudprovider "k8s.io/cloud-provider"

Discussion:
What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
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
Change:
- name: kibana-logging image: docker.elastic.co/kibana/kibana:5.5.1 resources: <del> # keep request = limit to keep this container in guaranteed class </del> <ins> # need more cpu upon initialization, therefore burstable class </ins> limits: <del> cpu: 100m </del> <ins> cpu: 1000m </ins> requests: cpu: 100m env:

Discussion:
Example: https://k8s- It seems there's not enough CPU to start in time
Change:
{ Name: podClaimName, Source: v1.ClaimSource{ <del> ResourceClaimTemplateName: utilpointer.String(pod.Name), </del> <ins> ResourceClaimTemplateName: ptr.To(pod.Name), </ins> }, }, }

Discussion:
In Aldo pointed out that: Let's use that instead of sleeping. /sig node /triage accepted /priority long-term More robust test.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### What would you like to be ? Aldo pointed out that: There is. There should be a Schedulable condition set to false in the PodStatus. /triage accepted /priority long-term ### Why is this needed? 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
/assign
Change:
apiService := curr.DeepCopy() apiService.Spec = desired.Spec _, err = c.apiServiceClient.APIServices().Update(apiService) <ins> if apierrors.IsNotFound(err) || apierrors.IsConflict(err) { // deleted or changed in the meantime, we'll get called again return nil } </ins> return err }

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
return true, podCopy, v1.PodResizeStatusInProgress } <del> func (kl *Kubelet) handlePodResourcesResize(pod *v1.Pod) { </del> <ins> func (kl *Kubelet) handlePodResourcesResize(pod *v1.Pod) *v1.Pod { </ins> if pod.Status.Phase != v1.PodRunning { <del> return </del> <ins> return pod </ins> } podResized := false for _, container := range pod.Spec.Containers {

Discussion:
mutates the pod object in place (vs creating a copy first). That's illegal and can cause data races or potentially panics (the panic is unlikely here but I can't rule it out). This line should be: This should be fixed because we might serialize the object in the middle of this from somewhere else and if the object changes midway the protobuf object we create may not be valid, leading to panics in kubelets with this gate turned on. /sig node /priority critical-urgent /kind bug /assign No mutation of pod objects from within methods (in fact no mutation of should occur in most loops). N/A No response <details</details<details</details<details</details<details</details<details</details<details</details
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
ACK. I'll fix it shortly.
is similar. is my try for both data races that we found.
One small , thanks.
Please review
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
Change:
defer called.Done() log.Infof("deferred action invoked") if next != idx { <del> t.Fatalf("expected index %d instead of %d", idx, next) </del> <ins> t.Errorf("expected index %d instead of %d", idx, next) </ins> } next++ })

Discussion:
Can we get this fixed ASAP? Thanks!
yep, thanks for reporting , Brendan Burns wrote:
how reproduceable is this? I have some changes that I think will resolve it but I couldn't reproduce locally even when all my cpu's were pretty tied up and using a high GOMAXPROCS.
flakey label process?
the labelling is due to me failing @ github's label interface. Bulk editing labels removes them if any of the selected things have the label sigh Thanks for the quick fix.
Change:
importpath = "k8s.io/kubernetes/pkg/scheduler/framework/plugins/nodepreferavoidpods", visibility = ["//visibility:public"], deps = [ <del> "//pkg/scheduler/algorithm/priorities:go_default_library", "//pkg/scheduler/framework/plugins/migration:go_default_library", </del> <ins> "//pkg/apis/core/v1/helper:go_default_library", </ins> "//pkg/scheduler/framework/v1alpha1:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", ], )

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
} // cleanupOrphanedPodDirs removes the volumes of pods that should not be <del> // running and that have no containers running. </del> <ins> // running and that have no containers running.  Note that we roll up logs here since it runs in the main loop. </ins> func (kl *Kubelet) cleanupOrphanedPodDirs( pods []*v1.Pod, runningPods []*kubecontainer.Pod) error { allPods := sets.NewString()

Discussion:
What we see in if any mismatches for volumes are around: The Problem: Obviously this can get pretty large. Since theres not much variability, it seems like rolling up all the orphanXYZ messages would be more useful and readable. Note this runs in the sync loop, so it happens every few (2) seconds for me. Obviously we see this worse on larger nodes (100 * n) / before but , I've only reproduced this on a local cluster for this PR.
Change:
return smallRCCount, mediumRCCount, bigRCCount } <del> func generateRCConfigs(totalPods int, image string, command []string, c *client.Client, nss []*api.Namespace) []*framework.RCConfig { </del> <ins> func generateRCConfigs(totalPods int, image string, command []string, nss []*api.Namespace) []*framework.RCConfig { </ins> configs := make([]*framework.RCConfig, 0) smallRCCount, mediumRCCount, bigRCCount := computeRCCounts(totalPods) <del> configs = append(configs, generateRCConfigsForGroup(c, nss, smallRCGroupName, smallRCSize, smallRCCount, image, command)...) configs = append(configs, generateRCConfigsForGroup(c, nss, mediumRCGroupName, mediumRCSize, mediumRCCount, image, command)...) configs = append(configs, generateRCConfigsForGroup(c, nss, bigRCGroupName, bigRCSize, bigRCCount, image, command)...) </del> <ins> configs = append(configs, generateRCConfigsForGroup(nss, smallRCGroupName, smallRCSize, smallRCCount, image, command)...) configs = append(configs, generateRCConfigsForGroup(nss, mediumRCGroupName, mediumRCSize, mediumRCCount, image, command)...) configs = append(configs, generateRCConfigsForGroup(nss, bigRCGroupName, bigRCSize, bigRCCount, image, command)...) // Create a number of clients to better simulate real usecase // where not everyone is using exactly the same client. rcsPerClient := 20 clients, err := createClients((len(configs) + rcsPerClient - 1) / rcsPerClient) framework.ExpectNoError(err) for i := 0; i < len(configs); i++ { configs[i].Client = clients[i%len(clients)] } </ins> return configs } <del> func generateRCConfigsForGroup(c *client.Client, nss []*api.Namespace, groupName string, size, count int, image string, command []string) []*framework.RCConfig { </del> <ins> func generateRCConfigsForGroup( nss []*api.Namespace, groupName string, size, count int, image string, command []string) []*framework.RCConfig { </ins> configs := make([]*framework.RCConfig, 0, count) for i := 1; i <= count; i++ { config := &framework.RCConfig{ <del> Client:     c, </del> <ins> Client:     nil, // this will be overwritten later </ins> Name:       groupName + "-" + strconv.Itoa(i), Namespace:  nss[i%len(nss)].Name, Timeout:    10 * time.Minute,

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
func NewStorageFactoryConfig() *StorageFactoryConfig { resources := []schema.GroupVersionResource{ <del> // TODO (https://github.com/kubernetes/kubernetes/issues/108451): remove the override in // 1.25. apisstorage.Resource("csistoragecapacities").WithVersion("v1beta1"), </del> <ins> // If a resource has to be stored in a version that is not the // latest, then it can be listed here. Usually this is the case // when a new version for a resource gets introduced and a // downgrade to an older apiserver that doesn't know the new // version still needs to be supported for one release. // // Example from Kubernetes 1.24 where csistoragecapacities had just // graduated to GA: // // TODO (https://github.com/kubernetes/kubernetes/issues/108451): remove the override in 1.25. // apisstorage.Resource("csistoragecapacities").WithVersion("v1beta1"), </ins> } return &StorageFactoryConfig{

Discussion:
The override in can be removed in Kubernetes v1.25 because then the oldest supported kube-apiserver for downgrades will be v1.24 which will understand the v1 format. Also need to adapt See and Code cleanup...
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
/sig storage
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]:
/remove-lifecycle stale /lifecycle frozen
Change:
fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, // Test case 1 fakeOK, fakeOK, fakeOK, fakeErr, fakeOK, fakeOK, fakeErr, fakeOK, fakeOK, fakeErr, fakeOK, <del> fakeOK, fakeOK, fakeOK, fakeOK, fakeErr, fakeOK, </del> <ins> fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeOK, fakeErr, fakeOK, fakeOK, fakeErr, fakeOK, fakeOK, fakeErr, fakeOK, </ins> }, } execer := fakeexec.FakeExec{

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: Run on a work node of kubernetes. Containers are killed, instead of exiting normally. Some resources are not released such as vips created by keepalived. What you expected to happen: The container exits properly so that system resources are released correctly How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: , line 139: Can I try to stop containers before removing them? Environment: Kubernetes version (use ): v1.18.5 Cloud provider or hardware configuration: OS (e.g: ): CentOS 7.4.1708 Kernel (e.g. ): 3.10.0-1127.18.2.el7.x86_64 Install tools: kubeadm
/sig cluster-lifecycle These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/area kubeadm /remove-kind bug /kind feature there is some discussion / Qs on the PR.
Change:
containerManager:     kubeDeps.ContainerManager, containerRuntimeName: containerRuntime, nodeIP:               parsedNodeIP, <ins> nodeIPValidator:      validateNodeIP, </ins> clock:                clock.RealClock{}, enableControllerAttachDetach:            kubeCfg.EnableControllerAttachDetach, iptClient:                               utilipt.New(utilexec.New(), utildbus.New(), utilipt.ProtocolIpv4),

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When using the flag on the kubelet, the node's list no longer reports , , addresses. What you expected to happen: That I can explicitly set to an IP, but the other addresses will still show up. How to reproduce it (as minimally and precisely as possible): Create a new kops cluster, modify the kubelet to use the flag with the eth0 on the node. Run Anything else we need to know?: This change will probably take place in  This came up as a result of Environment: Kubernetes version (use ): 1.9.x Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): any Kernel (e.g. ): any Install tools: kops /sig network /sig node I'll make a PR for this change shortly