jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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).

Related discussion:
text: apiVersion: v1 kind: Service metadata: <del> name: coredns </del> <ins> name: kube-dns </ins> namespace: kube-system labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "CoreDNS" spec: selector: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> clusterIP: $DNS_SERVER_IP ports: - name: dns
Code change:
<!-- 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).

Related discussion:
text: readonly UUID_MNT_PREFIX="/mnt/disks/by-uuid/google-local-ssds" readonly UUID_BLOCK_PREFIX="/dev/disk/by-uuid/google-local-ssds" <ins> readonly COREDNS_AUTOSCALER="Deployment/coredns" readonly KUBEDNS_AUTOSCALER="Deployment/kube-dns" </ins> # Use --retry-connrefused opt only if it's supported by curl. CURL_RETRY_CONNREFUSED=""
Code change:
<!-- 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).

Related discussion:
text: 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.
Code change:
<!-- 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).

Related discussion:
text: if [[ "${ENABLE_DNS_HORIZONTAL_AUTOSCALER:-}" == "true" ]]; then setup-addon-manifests "addons" "dns-horizontal-autoscaler" "gce" <ins> local -r dns_autoscaler_file="${dst_dir}/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml" sed -i'' -e "s@{{.Target}}@${KUBEDNS_AUTOSCALER}@g" "${dns_autoscaler_file}" </ins> fi }
Code change:
/sig gcp /sig cluster-life-cycle /kind flake /milestone v1.10 cc https://k8s- starting last night /assign can one of you verify?
/kind bug /priority important-soon
/priority critical-urgent /priority failing-test /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/assign according to , gonna move those jobs to us-central1-c instead

Related discussion:
text: containers: - name: influxdb image: gcr.io/google_containers/heapster_influxdb:v0.3 <ins> ports: - containerPort: 8083 hostPort: 8083 - containerPort: 8086 hostPort: 8086 </ins> - name: grafana image: gcr.io/google_containers/heapster_grafana:v0.6 env:
Code change:
/sig gcp /sig cluster-life-cycle /kind flake /milestone v1.10 cc https://k8s- starting last night /assign can one of you verify?
/kind bug /priority important-soon
/priority critical-urgent /priority failing-test /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/assign according to , gonna move those jobs to us-central1-c instead

Related discussion:
text: containers: - image: gcr.io/google_containers/heapster_influxdb:v0.3 name: influxdb <ins> ports: - containerPort: 8083 hostPort: 8083 - containerPort: 8086 hostPort: 8086 </ins> - name: grafana image: gcr.io/google_containers/heapster_grafana:v0.6 env:
Code change:
/kind bug What happened: We had a pod with persistent storage. We drained the node. The node VM was deleted. The PV was not attached to the node that the Pod migrated too. The kube-controller-manager logs contained the following. What you expected to happen: The PV can be attached to the node it was migrated to. How to reproduce it (as minimally and precisely as possible): Create a 2 node cluster on vSphere Deploy a pod with persistent storage attached Drain the node Delete the node VM immediately after draining Anything else we need to know?: The issue seems to be in the call to getVSphereInstance. This will return an error if the Node doesn't exist. Precluding the logic on line 804-813 from being executed. A restart of the kube-controller-manager resolved the issue. The following e2e test is not triggered in vSphere environments - Which might expose the issue. Environment: Kubernetes version (use ): 1.9.5 Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): ubuntu Kernel (e.g. ): Install tools: CFCR Others: /sig storage /sig vmware
More logs:
/assign

Related discussion:
text: defer cancel() vsi, err := vs.getVSphereInstance(nodeName) if err != nil { <ins> // If node doesn't exist, disk is already detached from node. if err == vclib.ErrNoVMFound { glog.Infof("Node %q does not exist, disk %s is already detached from node.", convertToString(nodeName), volPath) return nil } </ins> return err } // Ensure client is logged in and session is valid
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: says: What you expected to happen: Don't suggest that -- as it doesn't actually do that when used. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: (This was reported in but that issue was closed) Environment: Kubernetes version (use ): (This is indeed head from today) Cloud provider or hardware configuration: macOS OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools:Others:
/sig cli
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
/remove-lifecycle stale

Related discussion:
text: // whether or not a container name was given via --container ContainerNameSpecified bool <del> Interactive            bool </del> Selector               string Object           runtime.Object
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: says: What you expected to happen: Don't suggest that -- as it doesn't actually do that when used. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: (This was reported in but that issue was closed) Environment: Kubernetes version (use ): (This is indeed head from today) Cloud provider or hardware configuration: macOS OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools:Others:
/sig cli
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
/remove-lifecycle stale

Related discussion:
text: cmd.Flags().StringVar(&o.SinceTime, "since-time", o.SinceTime, i18n.T("Only return logs after a specific date (RFC3339). Defaults to all logs. Only one of since-time / since may be used.")) cmd.Flags().DurationVar(&o.SinceSeconds, "since", o.SinceSeconds, "Only return logs newer than a relative duration like 5s, 2m, or 3h. Defaults to all logs. Only one of since-time / since may be used.") cmd.Flags().StringVarP(&o.Container, "container", "c", o.Container, "Print the logs of this container") <del> cmd.Flags().BoolVar(&o.Interactive, "interactive", o.Interactive, "If true, prompt the user for input when required.") cmd.Flags().MarkDeprecated("interactive", "This flag is no longer respected and there is no replacement.") </del> cmdutil.AddPodRunningTimeoutFlag(cmd, defaultPodLogsTimeout) cmd.Flags().StringVarP(&o.Selector, "selector", "l", o.Selector, "Selector (label query) to filter on.") return cmd
Code change:
https://k8s- Please work on finding a fix for the flake. /priority failing-test /priority important-soon /sig api-machinery /kind flake
/assign
I think this was fixed by
we had a failure on 3/28 (after the above fix merged). https://k8s- Looking at the logs this seems to be a different error than the one fixed by . Can you confirm plz?
Hmm that is different, and I will look into the reason.
There hasn't been a failure since 3/28, So while the test might have flakes it is definitely less flaky than 12 failures per week now
Yes the latest runs look good. Please close the issue
/close

Related discussion:
text: }, }, Spec: v1.PodSpec{ <del> ActiveDeadlineSeconds: int64ptr(20), </del> Containers: []v1.Container{ { Name:  "example",
Code change:
https://k8s- Please work on finding a fix for the flake. /priority failing-test /priority important-soon /sig api-machinery /kind flake
/assign
I think this was fixed by
we had a failure on 3/28 (after the above fix merged). https://k8s- Looking at the logs this seems to be a different error than the one fixed by . Can you confirm plz?
Hmm that is different, and I will look into the reason.
There hasn't been a failure since 3/28, So while the test might have flakes it is definitely less flaky than 12 failures per week now
Yes the latest runs look good. Please close the issue
/close

Related discussion:
text: expectNoEvent(watchB, watch.Added, testPodA) testPodA, err = updatePod(f, testPodA.GetName(), func(p *v1.Pod) { <del> p.Spec.ActiveDeadlineSeconds = int64ptr(10) </del> <ins> p.ObjectMeta.Labels["mutation"] = "1" </ins> }) Expect(err).NotTo(HaveOccurred()) expectEvent(watchA, watch.Modified, testPodA)
Code change:
https://k8s- Please work on finding a fix for the flake. /priority failing-test /priority important-soon /sig api-machinery /kind flake
/assign
I think this was fixed by
we had a failure on 3/28 (after the above fix merged). https://k8s- Looking at the logs this seems to be a different error than the one fixed by . Can you confirm plz?
Hmm that is different, and I will look into the reason.
There hasn't been a failure since 3/28, So while the test might have flakes it is definitely less flaky than 12 failures per week now
Yes the latest runs look good. Please close the issue
/close

Related discussion:
text: expectNoEvent(watchB, watch.Modified, testPodA) testPodA, err = updatePod(f, testPodA.GetName(), func(p *v1.Pod) { <del> p.Spec.ActiveDeadlineSeconds = int64ptr(5) </del> <ins> p.ObjectMeta.Labels["mutation"] = "2" </ins> }) Expect(err).NotTo(HaveOccurred()) expectEvent(watchA, watch.Modified, testPodA)
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Many service related test cases in test case are flaky. Especially related cases. CI Link: http://k8s- What you expected to happen: IPVS should sync rules within . How to reproduce it (as minimally and precisely as possible): a cluster with ipvs proxy mode, and specify . a service with backends. check the delay from create service to sync ipvs rules. (This issue is probabilistic, about 50% possibility to happened.)
/sig network /area ipvs
/assign

Related discussion:
text: func (proxier *Proxier) OnEndpointsSynced() { proxier.mu.Lock() proxier.endpointsSynced = true <ins> proxier.setInitialized(proxier.servicesSynced && proxier.endpointsSynced) </ins> proxier.mu.Unlock() <ins> // Sync unconditionally - this is called once per lifetime. </ins> proxier.syncProxyRules() }
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Deploying kube-proxy with mode ipvs on a system with the required ipvs support compiled into the kernel rather than as modules causes the kube-proxy deployment to fall back to using iptables. tryIPVSProxy is only checking for the presence of kernel modules and not if the running kernel has the required support compiled in. What you expected to happen: tryIPVSProxy should succeed if either the required modules are found or support is compiled into the running kernel. How to reproduce it (as minimally and precisely as possible): Boot a system using a kernel with ipvs support compiled in rather than as a module (such as the kernel used by and a host without iptables installed Add --config=/etc/kubernetes/kubelet- to the kubelet arguments using the following kubelet- contents: Install using kubeadm with the following config: Check the output of the kube-proxy pod: Anything else we need to know?: From , it should be possible to check for the existence of modules.builtin and if present use that in addition to using modprobe and the contents of /proc/modules. Environment: Kubernetes version (use ): v1.10.2 Cloud provider or hardware configuration: local kvm host OS (e.g. from /etc/os-release): custom linuxkit build Kernel (e.g. ): Linux linuxkit- 4.14.40-linuxkit SMP Thu May 10 10:06:57 UTC 2018 x86_64 Linux Install tools: kubeadm
/sig network
/cc
cc
cc please take a look.

Related discussion:
text: import ( "bytes" "fmt" <ins> "io/ioutil" </ins> "net" <ins> "regexp" </ins> "strconv" "strings" "sync"
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Deploying kube-proxy with mode ipvs on a system with the required ipvs support compiled into the kernel rather than as modules causes the kube-proxy deployment to fall back to using iptables. tryIPVSProxy is only checking for the presence of kernel modules and not if the running kernel has the required support compiled in. What you expected to happen: tryIPVSProxy should succeed if either the required modules are found or support is compiled into the running kernel. How to reproduce it (as minimally and precisely as possible): Boot a system using a kernel with ipvs support compiled in rather than as a module (such as the kernel used by and a host without iptables installed Add --config=/etc/kubernetes/kubelet- to the kubelet arguments using the following kubelet- contents: Install using kubeadm with the following config: Check the output of the kube-proxy pod: Anything else we need to know?: From , it should be possible to check for the existence of modules.builtin and if present use that in addition to using modprobe and the contents of /proc/modules. Environment: Kubernetes version (use ): v1.10.2 Cloud provider or hardware configuration: local kvm host OS (e.g. from /etc/os-release): custom linuxkit build Kernel (e.g. ): Linux linuxkit- 4.14.40-linuxkit SMP Thu May 10 10:06:57 UTC 2018 x86_64 Linux Install tools: kubeadm
/sig network
/cc
cc
cc please take a look.

Related discussion:
text: // GetModules returns all installed kernel modules. func (handle *LinuxKernelHandler) GetModules() ([]string, error) { <ins> // Check whether IPVS required kernel modules are built-in kernelVersionFile := "/proc/sys/kernel/osrelease" b, err := ioutil.ReadFile(kernelVersionFile) if err != nil { glog.Errorf("Failed to read file %s with error %v", kernelVersionFile, err) } kernelVersion := strings.TrimSpace(string(b)) builtinModsFilePath := fmt.Sprintf("/lib/modules/%s/modules.builtin", kernelVersion) b, err = ioutil.ReadFile(builtinModsFilePath) if err != nil { glog.Errorf("Failed to read file %s with error %v", builtinModsFilePath, err) } var bmods []string for _, module := range ipvsModules { if match, _ := regexp.Match(module+".ko", b); match { bmods = append(bmods, module) } } </ins> // Try to load IPVS required kernel modules using modprobe first for _, kmod := range ipvsModules { err := handle.executor.Command("modprobe", "--", kmod).Run()