jiebi/CodeConvo huggingface dataset:
Change:
cmd.Flags().Var(&options.server, clientcmd.FlagAPIServer, clientcmd.FlagAPIServer+" for the cluster entry in kubeconfig") cmd.Flags().Var(&options.apiVersion, clientcmd.FlagAPIVersion, clientcmd.FlagAPIVersion+" for the cluster entry in kubeconfig") <del> cmd.Flags().Var(&options.insecureSkipTLSVerify, clientcmd.FlagInsecure, clientcmd.FlagInsecure+" for the cluster entry in kubeconfig") </del> <ins> f := cmd.Flags().VarPF(&options.insecureSkipTLSVerify, clientcmd.FlagInsecure, "", clientcmd.FlagInsecure+" for the cluster entry in kubeconfig") f.NoOptDefVal = "true" </ins> cmd.Flags().Var(&options.certificateAuthority, clientcmd.FlagCAFile, "path to "+clientcmd.FlagCAFile+" for the cluster entry in kubeconfig") <del> cmd.Flags().Var(&options.embedCAData, clientcmd.FlagEmbedCerts, clientcmd.FlagEmbedCerts+" for the cluster entry in kubeconfig") </del> <ins> f = cmd.Flags().VarPF(&options.embedCAData, clientcmd.FlagEmbedCerts, "", clientcmd.FlagEmbedCerts+" for the cluster entry in kubeconfig") f.NoOptDefVal = "true" </ins> return cmd }

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
type fakeRoutesClient struct { mutex     *sync.Mutex FakeStore map[string]map[string]network.Route <ins> Calls     []string </ins> } func newFakeRoutesClient() *fakeRoutesClient {

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: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign
Change:
// update the kubelet config with old values updateKubeletConfig(f, oldCfg) <ins> // wait until the kubelet health check will pass and will continue to pass for specified period of time gomega.Eventually(func() bool { return kubeletHealthCheck(kubeletHealthCheckURL) }, time.Minute, 10*time.Second).Should(gomega.BeTrue()) gomega.Consistently(func() bool { return kubeletHealthCheck(kubeletHealthCheckURL) }, time.Minute, 10*time.Second).Should(gomega.BeTrue()) </ins> }) ginkgo.Context("with static policy", func() {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --kubelet-serial-gce-e2e-memory-manager no specific test, because the failure happens during waiting for the kubelet to come back after the restart the memory manager under the teardown, updates the kubelet configuration via dynamic configuration - because of the update, the kubelet health check is not responding for some short time period - e2e node service restart the kubelet - next memory manager test started and it stops the kubelet - the e2enode service fails on the initial health check - to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
/sig node
/triage accepted
Change:
import ( "fmt" "path" <del> "strings" </del> "time" "k8s.io/api/core/v1"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Table-based e2e tests are not getting updated to leading to the following error- ( mentioned in ) framework.ConformanceIt() requires the first parameter to be and are associated with at runtime based on different cases/test-scenarios. What you expected to happen: Either disapprove the use of table-based e2e tests or suggestion on an alternative approach to add such tests to Conformance. How to reproduce it (as minimally and precisely as possible): framework.ConformanceIt() to . /area conformance cc
/sig testing
/cc
Approaches to work around this: wrap the whole table based test in a ConformanceIt block refactor to a more boilerplate approach that has a ConformanceIt block for each table entry update the conformance test walker to detect table based tests that use a well known field?
Thanks I am evaluating these approaches especially on "conformance test walker" to retrieve well-known fields like and variables used inside .
Does this close if closes or are there other tests that need to transition?
This issue would be No other e2e test needs the transition from table-based test structure. Though "only one" remaining test should be restructured as an individual test.
/close Closing as per other fruitful approach and efforts would be taken to refactor table-based tests into individual tests wherever needed.
Closing this issue. <detailsIn response to : /close Closing as per other fruitful approach and efforts would be taken to refactor table-based tests into individual tests wherever 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
Change:
return pod } <del> // TestCleanup cleans both server and client pods. func TestCleanup(f *framework.Framework, config TestConfig) { </del> <ins> // TestServerCleanup cleans server pod. func TestServerCleanup(f *framework.Framework, config TestConfig) { </ins> ginkgo.By(fmt.Sprint("cleaning the environment after ", config.Prefix)) defer ginkgo.GinkgoRecover() <del> cs := f.ClientSet err := e2epod.DeletePodWithWaitByName(cs, config.Prefix+"-client", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-client", config.Namespace) if config.ServerImage != "" { err := e2epod.DeletePodWithWaitByName(cs, config.Prefix+"-server", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-server", config.Namespace) </del> <ins> if config.ServerImage == "" { return </ins> } <ins> err := e2epod.DeletePodWithWaitByName(f.ClientSet, config.Prefix+"-server", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-server", config.Namespace) </ins> } func runVolumeTesterPod(client clientset.Interface, config TestConfig, podSuffix string, privileged bool, fsGroup *int64, tests []Test) (*v1.Pod, error) {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in
Change:
return err } <del> if err := clientcmd.ModifyConfig(o.configAccess, *config, false); err != nil { return err } return nil </del> <ins> return clientcmd.ModifyConfig(o.configAccess, *config, false) </ins> } func (o *unsetOptions) complete(cmd *cobra.Command) error { endingArgs := cmd.Flags().Args() if len(endingArgs) != 1 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", endingArgs) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", endingArgs) </ins> } o.propertyName = endingArgs[0]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
sed -i -e "s@{{ *pillar['dns_domain'] *}}@${DNS_DOMAIN}@g" "${coredns_file}" sed -i -e "s@{{ *pillar['dns_server'] *}}@${DNS_SERVER_IP}@g" "${coredns_file}" sed -i -e "s@{{ *pillar['service_cluster_ip_range'] *}}@${SERVICE_CLUSTER_IP_RANGE}@g" "${coredns_file}" <ins> if [[ "${ENABLE_DNS_HORIZONTAL_AUTOSCALER:-}" == "true" ]]; then setup-addon-manifests "addons" "dns-horizontal-autoscaler" "gce" local -r dns_autoscaler_file="${dst_dir}/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml" sed -i'' -e "s@{{.Target}}@${COREDNS_AUTOSCALER}@g" "${dns_autoscaler_file}" fi </ins> } # Sets up the manifests of Fluentd configmap and yamls for k8s addons.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
NumStats:               3, NumSamples:             2, CpuUsagePercentiles:    []int{10, 50, 90}, <del> MemoryUsagePercentages: []int{10, 80, 90}, </del> <ins> MemoryUsagePercentiles: []int{10, 80, 90}, </ins> } containerName := "/some/container" cinfo := itest.GenerateRandomContainerInfo(containerName, 4, query, 1*time.Second)

Discussion:
release-master-informing capg-conformance-main-ci-artifacts Kubernetes e2e suite.BeforeSuite 05-25 06:37 IST Failure Error waiting for all pods to be running and ready: 3 / 13 pods in namespace kube-system are NOT in RUNNING and READY state in 10m0s No response /sig network /sig node 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
/remove sig-network /remove sig-node /unassign This seems a deployment problem ... on calico to be precise first point of contact for initial triage should be the job/sig owners ... this job also seems to be failing for a long time /sig cluster-lifecycle sig-cluster-lifecycle-cluster-api-alerts
/remove-sig network /remove-sig node
cc
will take a look /assign
Check the Calico version, there was a similar report that was fixed bumping the version. As a side not, I'm seeing a lot of problems related to Lots of projects/test/code were assuming the secret was created and is causing a lot of noise in different CIs
Hey thanks for the PR! The test still shows in the - will it take some time for the changes you made in the PR to reflect?
hello! those are not failures, they are flakys :/ afaik
Hey folks, this test has now started failing again on the dashboard. Should we open a new issue for it or is it okay to track it here itself? !
checking that
the capg conformance failed but now have flakys only
Thanks a ton
Change:
"integration", ], deps = [ <ins> "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library",

Discussion:
Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by
Change:
// resizeFileSystem will resize the file system if user has requested a resize of // underlying persistent volume and is allowed to do so. <del> resizeSimpleError, resizeDetailedError := og.resizeFileSystem(volumeToMount, devicePath, deviceMountPath, volumePlugin.GetPluginName()) </del> <ins> resizeSimpleError, resizeDetailedError := og.resizeFileSystem(volumeToMount, devicePath, deviceMountPath, volumePluginName) </ins> if resizeSimpleError != nil || resizeDetailedError != nil { return resizeSimpleError, resizeDetailedError

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!--What happened: In this test, volume mount failed because the driver-registrar took a minute to come up. However, it seems like volume mount operation is retrying without any sort of backoff. This message appears in 400+ times in less than a minute. What you expected to happen: Operation executor should not be retrying operations so frequently. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'll take a look at this. /assign
Problem is that reconciler depends on operation executor to do backoff. In the normal case operation executor returns a method that does the actual work. Any errors by that method result in exponential backoff. But in this case, the error is coming from the code creating the mount method which is not handled by the back off logic, and is called again and again by the reconciler resulting in log and event spam. This didn't use to be a problem because initialization errors were uncommon (plugins were built in), but with CSI the driver may not exist and these initialization errors are expected. I'll look in to cleaning this up.
Is this something that will affect users in 1.13 and needs CPing?
This will result in kubelet log spam and possibly kubernetes event spam. It happens when someone creates a pod referencing a CSI volume before the CSI driver for that volume is installed. Which happens frequently in E2E tests because they install/remove driver with every test. But should be rare in real world usage since most users are likely to install a driver first before using it.
If release team is worried about this, we could create a quick PR to suppress logging/event generation of this these errors. Otherwise we plan to address this more holistically for 1.14 and 1.13.1.
Change:
"k8s.io/kubernetes/plugin/pkg/scheduler/factory" "github.com/golang/glog" <ins> "github.com/prometheus/client_golang/prometheus" </ins> "github.com/spf13/cobra" "github.com/spf13/pflag" <del> utilflag "k8s.io/apiserver/pkg/util/flag" "github.com/prometheus/client_golang/prometheus" </del> ) // SchedulerServer has all the context and params needed to run a Scheduler

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I pull the latest code, and run with below cmd. But the cluster is not up. And I notice the kube-, What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): GitCommit:"" Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cluster-lifecycle
/assign
Can you please try the fix above?
/assign
/unassign
your pr does not fix it yet? If not, I can help.
The fix from works for me! o/
ok, thanks
reopen , make less modifications.
sorry, i miss hyper...
Change:
package algorithmprovider import ( <del> "sort" "strings" </del> <ins> "fmt" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/klog/v2"

Discussion:
Using scheduler like or , it always get unwanted output like: It simply because when adding the flags in scheduler, it will try to look up the And this will invoke: Since flag already has to prevent running other code when having : We should not print the klog info when using or right?
/sig scheduling
that's annoying. Can you help to fix it?
Ok I'll take care of this. /assign
Change:
Manager: m, } <del> // Export the HTTP endpoint if a port was specified. if port > 0 { err = cadvisorClient.exportHTTP(port) if err != nil { return nil, err } </del> <ins> err = cadvisorClient.exportHTTP(port) if err != nil { return nil, err </ins> } return cadvisorClient, nil }

Discussion:
If is passed to the kubelet, container metrics are not included in the Prometheus metrics endpoint.
Change:
t.Run(test.name, func(t *testing.T) { nodes := makeNodeList(test.nodes) snapshot := cache.NewSnapshot(test.pods, nodes) <del> ctx := context.Background() </del> <ins> ctx, cancel := context.WithCancel(context.Background()) defer cancel() </ins> informerFactory, err := populateAndStartInformers(ctx, test.rcs, test.rss, test.services, test.sss) if err != nil { t.Errorf("error creating informerFactory: %+v", err)

Discussion:
The ctx object () is context.Background(). Thus, its Done() method returns a nil channel. Later, the nil channel is used to call and as their argument. The goroutines created in the two functions are leaked. No goroutine leaks in TestSelectorSpreadScore(). Run TestSelectorSpreadScore() No response all versions after <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
/sig scheduling (It sounds like leas in unit tests, which may be negligible. Does it cause some test failures?)
the test can pass.
/assign
/unassign /assign
Change:
"k8s.io/apimachinery/pkg/watch" "k8s.io/apiserver/pkg/features" "k8s.io/apiserver/pkg/storage" <ins> "k8s.io/apiserver/pkg/storage/cacher/metrics" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/tools/cache" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> k8smetrics "k8s.io/component-base/metrics" "k8s.io/component-base/metrics/testutil" </ins> "k8s.io/utils/clock" testingclock "k8s.io/utils/clock/testing" )

Discussion:
Part of From For now posted as a "help wanted" issue, however if we cannot hit the timeline for 1.30 code freeze () I would take it over so we don't miss. Still issue is simple enough that it can be quickly implemented. Implementation tips: Add a metric around waitUnitlFreshAndBlock method Metric should be a histogram with latency buckets similar to api latency Metric should have label for resource version. A way to monitor watch cache impact on request latency.
/sig api-machinery /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig api-machinery /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
`monit` is a lightweight process babysitting system for keeping kubelet and docker running. <ins> ### fluentd `fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging). </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/cluster-components.md?pixel)]()

Discussion:
has TODOs for how to bring up cluster addons like monitoring and logging. We should fill these in. requested by user: