jiebi/CodeConvo huggingface dataset:
Change:
done for var in "${__kubectl_override_flag_list[@]##*-}"; do if eval "test -n "$${var}""; then <del> eval "echo ${${var}}" </del> <ins> eval "echo -n ${${var}}' '" </ins> fi done }

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 kubectl v1.16.0-alpha.2, completion with override flags fails. then hit TAB will produce error "resource type must be specified" What you expected to happen: It must show the namespaces without error. How to reproduce it (as minimally and precisely as possible): With kubectl v1.16.0-alpha.2, then hit TAB key. Anything else we need to know?: It looks like introduced this regression. Environment: Kubernetes version (use ): kubectl v1.16.0-alpha.2 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 cli
I also reproduced this bug with the following steps:
I'm fixing it.
Change:
objects = append(objects, template, pod) b.create(ctx, objects...) <del> // There's no way to be sure that the scheduler has checked the pod. // But if we sleep for a short while, it's likely and if there are any // bugs that prevent the scheduler from handling creation of the class, // those bugs should show up as test flakes. // // TODO (https://github.com/kubernetes/kubernetes/issues/123805): check the Schedulable condition instead of // sleeping. time.Sleep(time.Second) </del> <ins> framework.ExpectNoError(e2epod.WaitForPodNameUnschedulableInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace)) </ins> class.UID = "" class.ResourceVersion = ""

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:
"type": "object" }, "io.k8s.api.networking.v1.IPBlock": { <del> "description": "IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", </del> <ins> "description": "IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", </ins> "properties": { "cidr": { <del> "description": "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"", </del> <ins> "description": "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64"", </ins> "type": "string" }, "except": { <del> "description": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" Except values will be rejected if they are outside the CIDR range", </del> <ins> "description": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range", </ins> "items": { "type": "string" },

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
<ins> { "template_k8s_logstash" : { "template" : "logstash-*", "settings" : { "index.refresh_interval" : "5s" }, "mappings" : { "_default_" : { "dynamic_templates" : [ { "kubernetes_field" : { "path_match" : "kubernetes.*", "mapping" : { "type" : "string", "index" : "not_analyzed" } } } ] } } } } </ins>

Discussion:
When i doing an elasticsearch aggs with the following statement: then, i got this: Actually, i want the pod names like this:
I have solved this problem by adding a index template for k8s logs. Now, I can aggregation pod names of the same namespace.
How are you sending your logs to elasticsearch? Using the default fluentd configuration?
First, I use the default fluentd configuration. Secondly, My application is written with nodejs language, using library.
Change:
glog.Fatalf("Failed to get supported resources from server: %v", err) } <del> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), &unversioned.APIVersions{}, s.NamespaceSyncPeriod) </del> <ins> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), versions, s.NamespaceSyncPeriod) </ins> namespaceController.Run(s.ConcurrentNamespaceSyncs, wait.NeverStop) groupVersion := "extensions/v1beta1"

Discussion:
Yet another case of not being deleted properly?
I can take a look in morning. Assign to me. I am blocked on generalizing the controller until the dynamic client is done. On Wednesday, February 10, 2016, Tim Hockin wrote:
Are you seeing this on HEAD? I had moved in a recent PR to call DeleteCollection instead of per item deletes. Possibly job has a bug there.
yes head , Derek Carr wrote:
- I see be bug. The list of version strings being passed to the controller got messed up in my last PR. I will send a patch soon.
I patched this into my cluster and it seems fixed, but the same problem exists for replicaset now.
Change:
- --running-in-cluster=false - --config-file-path=/etc/gce.conf - --healthz-port=8086 <del> - --enable-endpoint-slices </del> - --gce-ratelimit=ga.Operations.Get,qps,10,100 - --gce-ratelimit=alpha.Operations.Get,qps,10,100 - --gce-ratelimit=beta.Operations.Get,qps,10,100

Discussion:
master-informing gce-master-scale-correctnessKubernetes e2e suite.[It] [sig-network] Services GCE [Slow] should be able to create and tear down a standard-tier load balancer [Slow] ! 2023-05-24 10:01 PDT Kubernetes e2e suite: [It] [sig-network] Services GCE [Slow] should be able to create and tear down a standard-tier load balancer [Slow] No response /sig scalability cc
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
Ok, checking job Download controller-manager logs There are these errors already reported in but that doesn't seem the problem This is weird does this ring a bell? ^^
It seems to be a flake which is passed in the last run.
Yes, I see the last run Green; so closing this as of now! Will re-open it if this will be a release blocker.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This seems like a flaky test. It has failed multiple times: cc
/remove-kind failing-test /kind flake
The load balancer tkes a lot of time to be provisioned and the test times out I'm going to bump the ingress-gce version used on the test because is too old and has some performance improvements that can solve this issue
/reopen we need to be completely sure this address the problem, it has to get at least 5/5 consecutive greens
Reopened this issue. <detailsIn response to : /reopen 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
It failed again:
Checking last occurrence we can find the logs on the kube-controller-manager So, the problem is that the time to acquire the IP takes too much, the test times out at and the IP is at IIUIC this depends on the underlay infra, what do we want to do with this, bump the timeout of the LB?
/assign
Update on the state of failures. The failures are becoming more frequent: !
Unfortunately I think bumping the timeout is our only option.
can you send a PR to move to 1 hours and add a comment referencing this issue?
Just created
CI is green since 06-27. /close
Closing this issue. <detailsIn response to : CI is green since 06-27. /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:
Name:     "test_clone", }, } <ins> validSpecNilAPIGroup := core.PersistentVolumeClaimSpec{ DataSource: &core.TypedLocalObjectReference{ Kind: "PersistentVolumeClaim", Name: "test_clone", }, } </ins> invalidAPIGroup := "invalid.pvc.api.group" invalidSpec := core.PersistentVolumeClaimSpec{

Discussion:
What happened: While implementing the new VolumePVCDataSource feature I discovered that even though the we don't use APIGroup (the appropriate setting is ) if the APIGroup is omitted it results in a nil pointer exception on the API server. What you expected to happen: APIGroup should be able to be omitted from the spec How to reproduce it (as minimally and precisely as possible): Create a spec to create a clone of a PVC with out the APIGroup parameter in the DataSource spec: The result will be an nil pointer exception during the verification of the datasource field. Adding the APIGroup entry will address this as a work-around: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.1.+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2019-06-12T22:12:02Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Install tools: local-up-
I have a simple fix, will post PR in a moment
/sig storage
/priority critical-urgent /milestone v1.15
Change:
ns := f.Namespace.Name c := f.Client // Create nginx pods. <del> podLabels := map[string]string{"name": "sample-pod"} </del> <ins> deploymentPodLabels := map[string]string{"name": "sample-pod"} rcPodLabels := map[string]string{ "name": "sample-pod", "pod":  "nginx", } </ins> rcName := "nginx-controller" _, err := c.ReplicationControllers(ns).Create(&api.ReplicationController{ ObjectMeta: api.ObjectMeta{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
// +build !ignore_autogenerated /* <del> Copyright 2017 The Kubernetes Authors. </del> <ins> Copyright 2018 The Kubernetes Authors. </ins> Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

Discussion:
Happy New Year! Now when I run make I get a diff like this in every zz_generated file: Not sure what a smart solution is, but we could merge something like in the meantime.
Change:
"time" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/registered" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/version" <ins> "github.com/golang/glog" </ins> ) // Config holds the common attributes that can be passed to a Kubernetes client on

Discussion:
This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc
Change:
metricsGrabber, err := metrics.NewMetricsGrabber(c, nil, true, false, true, false, false) if err != nil { <del> framework.Failf("Error creating metrics grabber : %v", err) </del> <ins> framework.ExpectNoError(err, "Error creating metrics grabber: %v", err) </ins> } if !metricsGrabber.HasRegisteredMaster() { <del> framework.Skipf("Environment does not support getting controller-manager metrics - skipping") </del> <ins> e2elog.Logf("Warning: Environment does not support getting controller-manager metrics") return opCounts{} </ins> } controllerMetrics, err := metricsGrabber.GrabFromControllerManager()

Discussion:
Example:
/assign
cc
For all those PD instances, tests are being skipped due to this line: Fixing it by removing that skip as suggested by
/open until we verify the issue is fixed
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Looks like diffResources became green on 5/27 /close
Closing this issue. <detailsIn response to : Looks like diffResources became green on 5/27 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:
"time" "github.com/stretchr/testify/assert" <ins> "github.com/stretchr/testify/require" </ins> internalapi "k8s.io/kubernetes/pkg/kubelet/apis/cri" apitest "k8s.io/kubernetes/pkg/kubelet/apis/cri/testing" fakeremote "k8s.io/kubernetes/pkg/kubelet/remote/fake"

Discussion:
A race condition between fakeremote.Start() is spawned as a goroutine to listen for connections, and its caller assumes that the listener will immediately be ready to accept connections. This leads to intermittent test failures if the caller attempts before the fake remote runtime is ready to listen. The code needs to be refactored so that the fake remote returns from listen, and then spawns the server as a goroutine and returns. This can be reproduced by running the remoteruntimetest in a loop; it fails periodically. Failure can be accelerated by putting a time.Sleep() in fake.Start() immediately before the call to util.CreateListener; the failure is then effectively deterministic. Fix tested by running about 150,000 iterations without observing any failures.
/sig pod
Reference initial issue:
/sig node
Change:
return &KubeletFlags{ ContainerRuntimeOptions: *NewContainerRuntimeOptions(), CertDirectory:           "/var/lib/kubelet/pki", <del> RootDirectory:           defaultRootDir, </del> <ins> RootDirectory:           filepath.Clean(defaultRootDir), </ins> MaxContainerCount:       -1, MaxPerPodContainerCount: 1, MinimumGCAge:            metav1.Duration{Duration: 0},

Discussion:
pull-kubernetes-unit, see example failure in It appears to be a new test in No response No response No response /sig
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
Repro's locally:
/cc can you PTAL? It seems related to new test in
flaking regularly -
actually, I'm not sure this is a test-only race... it looks like self mutates , and that is called in a goroutine in parallel with other methods that access rootDirectory: I suspect this has always been a race, and the unit test is exercising / catching it more
moving the filepath.Clean to init time: and changing the check in setupDataDirs to be a validation rather than a mutation: might resolve the immediate race
/assign
is open to fixing it. The data race we find here should be fixed. However, is another one that we need to fix. I add a new commit to fix that as well.
did you see that race as well or did you just see the issue opened? that was in a code path that should be feature gated so I wouldn't have expected it to trigger in the kubemark unit tests
I may mixed problems together. Yes. will not trigger in the kubemark unit tests. Using stressing, I find the data race cannot fix the problem completely. Then I saw and cherry-picked the fix to my PR. But the hollowNode test still flakes and I looked into it and find it is the volumeManager problem. is just another potential data race in .

the rootDirectory and volumeManagerSyncTime race fixes are easy to reason about and fix code that looks like it could really race in currently enabled-by-default code looks like a real race in disabled-by-default code. I'll defer to kubelet folks and whether to mix that fix into
I think I should drop that fix. This will make things more clear.
Change:
ginkgo.By(fmt.Sprintf("Rechecking if the volume in pod%d exists as expected volume mode (%s)", index, *pvc.Spec.VolumeMode)) utils.CheckVolumeModeOfPath(f, pod, *pvc.Spec.VolumeMode, "/mnt/volume1") <ins> if readOnly { ginkgo.By("Skipping volume content checks, volume is read-only") continue } </ins> if i == 0 { // This time there should be data that last pod wrote, for 1st pod ginkgo.By(fmt.Sprintf("From pod%d, rechecking if reading the data that last pod write works properly", index))

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
expectedError: ErrCredentialMissing, }, { <ins> testName: "FQIN stored as lowercase", data: map[string][]byte{ testServerFQIN + ".username": []byte(testUsername), testServerFQIN + ".password": []byte(testPassword), }, config: map[string]*Credential{ strings.ToLower(testServerFQIN): { User:     testUsername, Password: testPassword, }, }, expectedError: nil, }, { </ins> testName: "IP with unknown key", data: map[string][]byte{ "10.20.30.40": []byte(testUsername),

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: kube-controller-manager is unable to locate the credentials of the vCenter host, even though they are defined and cased identically to the hostname in the cloud-provider-config. What you expected to happen: vCenter hostname should not be case-sensitive, or should be documented that it is. It should successfully locate credentials from the manager How to reproduce it (as minimally and precisely as possible): to an upper-case name kube-controller-manager daemon to update the secret to provision storage with the "thin" storage class will stay suck in pending Anything else we need to know?: Log Messages: ` This appears to be induced by the way the vCenter server name is calculated when the secret containing the credentials is parsed[]. The credentialKey is converted to lower case and is then parsed to lookup the server name. Environment: Kubernetes version (use ): v1.14 Cloud provider or hardware configuration: vSphere OS (e.g: ): Unknown Kernel (e.g. ): Unknown Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area/provider/vmware
/area provider/vmware
Change:
return nil } <del> return migration.PredicateResultToFrameworkStatus([]predicates.PredicateFailureReason{predicates.ErrServiceAffinityViolated}, nil) </del> <ins> return framework.NewStatus(framework.Unschedulable, ErrServiceAffinityViolated) </ins> } // Score invoked at the Score extension point.

Discussion:
Part of See example /sig scheduling /kind cleanup /help /priority important-soon
/assign /remove-help
Change:
SupportedVersions: []*csipb.Version{ {Major: 0, Minor: 0, Patch: 1}, {Major: 0, Minor: 1, Patch: 0}, <ins> {Major: 0, Minor: 2, Patch: 0}, </ins> {Major: 1, Minor: 0, Patch: 0}, {Major: 1, Minor: 0, Patch: 1}, {Major: 1, Minor: 1, Patch: 1},

Discussion:
Current CSI E2E test has some issues which prevent it to run successfully the a local cluster. /sig storage /kind bug /assign