jiebi/CodeConvo huggingface dataset:
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: go install ./cmd/... # Use eval to preserve embedded quoted strings. <del> eval "goflags=(${KUBE_GOFLAGS:-})" </del> <ins> eval "goflags=(${GOFLAGS:-})" </ins> # Filter out arguments that start with "-" and move them to goflags. targets=()
Code change:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign

Related discussion:
text: echo '    make test-integration' echo echo "The following invocation will run a specific test with the verbose flag set: " <del> echo '    make test-integration WHAT=./test/integration/pods KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </del> <ins> echo '    make test-integration WHAT=./test/integration/pods GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </ins> echo exit 1
Code change:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig azure
fixed by
/label official-cve-feed (Related to kubernetes/sig-security)

Related discussion:
text: // if container doesn't exist, create one and retry PutPageBlob detail := err.Error() if strings.Contains(detail, errContainerNotFound) { <del> err = blobClient.CreateContainer(vhdContainerName, azs.ContainerAccessTypeContainer) </del> <ins> err = blobClient.CreateContainer(vhdContainerName, azs.ContainerAccessTypePrivate) </ins> if err == nil { err = blobClient.PutPageBlob(vhdContainerName, name, vhdSize, tags) }
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?: BUG REPORT What happened: When using IPv6 addresses, the kubelet passes the address to client-go, which does not correctly format the address for use in API requests. For example: Failed to list v1.Pod: Get https://2001:129::136:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dnode136&resourceVersi on=0: dial tcp: too many colons in address 2001:129::136:6443 What you expected to happen: The URI should have https://[2001:129::136]:6443, so that SplitHostPort() will correctly be able to separate the host and port components. How to reproduce it (as minimally and precisely as possible): Create cluster using IPv6 address (e.g. kubeadm init --apiserver-advertise-address=2001:129::136). When the kubelet starts up, it'll log this error. Anything else we need to know?: This is being handled as part of effort to support IPv6 in Kubernetes. Was found by a co-worker, I'll work on a commit to fix. Environment: Kubernetes version (use ): Using latest, via KubeAdm Cloud provider or hardware configuration*: bare-metal OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-81-generic Install tools: Using KubeAdm Others:
/area client-libraries /area kubelet /area ipv6
/assign
The point of failure is here: SplitHostPort will accept IPv4 and IPv6 addresses, but the latter must have square brackets around the IPv6 address.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery because client-go
Should we open this on the repository?
I see in the client-go repo read me that it states: Does that confirm that I should do a PR here?
One thing that I was wonder, was whether or not the hostname/address provided in the call to getListener, has been validated. If so, and it can only be a hostname, IPv4, or IPv6 address as a string, we could just check if there is a ":" in the name to determine IPv6. Otherwise, I could use net.ParseIP(), and net.To4() to determine if IPv6. I'll start working with the latter assumption, but please let me know, if the former could be used.
Also, I'm making the assumption that we'd want to make client-go be able to handle IPv6 addresses, rather than having each user of client-go (e.g. kubelet) from ensuring that the IP address is of the right form. IOW, have client-go add the needed [] around IPv6 addresses, rather than have kubelet do that. My thought is that there may be cases where we want just the IP address and not the modified IP. Does that sound OK?

Related discussion:
text: Protocol:         "tcp6", ShouldRaiseError: true, }, <del> { // IPv6 address must be put into brackets. This test reveals this. Hostname:         "::1", Protocol:         "tcp6", ShouldRaiseError: true, }, </del> } for i, testCase := range testCases {
Code change:
We want kubemark setups to be as similar to real clusters as possible. Since we are launching kube-aggregator in real clusters, we should add a possibility (and probably also enable by default) to have kube-aggregator in front of apiserver(s).
was working on being able to use it in e2es.
With kube-aggregator integrated into kube-apiserver, is this still relevant?
There are a few flags which need to be set up for kubemark to actually be properly testing with the aggregator. I am digging around in that code this week anyway. I will try to get to it and make sure its set up properly.
Thanks for looking. Let me know if I you need something.
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 3 days, the issue will be moved out of the v1.8 milestone. kind: Must specify at most one of ['kind/bug', 'kind/feature', 'kind/cleanup']. priority: Must specify at most one of ['priority/critical-urgent', 'priority/important-soon', 'priority/important-longterm']. <detailsAdditional instructions available <a href=""here</a</details

Related discussion:
text: fi params+=" --tls-cert-file=/etc/srv/kubernetes/server.cert" params+=" --tls-private-key-file=/etc/srv/kubernetes/server.key" <ins> params+=" --requestheader-client-ca-file=/etc/srv/kubernetes/aggr_ca.crt" params+=" --requestheader-allowed-names=aggregator" params+=" --requestheader-extra-headers-prefix=X-Remote-Extra-" params+=" --requestheader-group-headers=X-Remote-Group" params+=" --requestheader-username-headers=X-Remote-User" params+=" --proxy-client-cert-file=/etc/srv/kubernetes/proxy_client.crt" params+=" --proxy-client-key-file=/etc/srv/kubernetes/proxy_client.key" params+=" --enable-aggregator-routing=true" </ins> params+=" --client-ca-file=/etc/srv/kubernetes/ca.crt" params+=" --token-auth-file=/etc/srv/kubernetes/known_tokens.csv" params+=" --secure-port=443"
Code change:
We want kubemark setups to be as similar to real clusters as possible. Since we are launching kube-aggregator in real clusters, we should add a possibility (and probably also enable by default) to have kube-aggregator in front of apiserver(s).
was working on being able to use it in e2es.
With kube-aggregator integrated into kube-apiserver, is this still relevant?
There are a few flags which need to be set up for kubemark to actually be properly testing with the aggregator. I am digging around in that code this week anyway. I will try to get to it and make sure its set up properly.
Thanks for looking. Let me know if I you need something.
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 3 days, the issue will be moved out of the v1.8 milestone. kind: Must specify at most one of ['kind/bug', 'kind/feature', 'kind/cleanup']. priority: Must specify at most one of ['priority/critical-urgent', 'priority/important-soon', 'priority/important-longterm']. <detailsAdditional instructions available <a href=""here</a</details

Related discussion:
text: sudo bash -c "echo ${CA_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/ca.crt" &&  sudo bash -c "echo ${MASTER_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/server.cert" &&  sudo bash -c "echo ${MASTER_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/server.key" &&  <ins> sudo bash -c "echo ${REQUESTHEADER_CA_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/aggr_ca.crt" &&  sudo bash -c "echo ${PROXY_CLIENT_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/proxy_client.crt" &&  sudo bash -c "echo ${PROXY_CLIENT_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/proxy_client.key" &&  </ins> sudo bash -c "echo ${KUBECFG_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/kubecfg.crt" &&  sudo bash -c "echo ${KUBECFG_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/kubecfg.key" &&  sudo bash -c "echo "${KUBE_BEARER_TOKEN},admin,admin" > /home/kubernetes/k8s_auth_data/known_tokens.csv" &&
Code change:
It looks like a test configuration failure:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/assign
last passing run: https://k8s- first failing run: https://k8s-
https://k8s- /close

Related discussion:
text: go run ./hack/e2e.go -v -build # Push to GCS <del> yes | ./build/push-ci-build.sh </del> <ins> ./build/push-ci-build.sh </ins> sha256sum _output/release-tars/kubernetes*.tar.gz
Code change:
/kind bug What happened: We constantly log message like at V(2) that don't tell any useful information.

Related discussion:
text: for portname := range oldPortsToEndpoints { svcPort := proxy.ServicePortName{NamespacedName: types.NamespacedName{Namespace: oldEndpoints.Namespace, Name: oldEndpoints.Name}, Port: portname} if _, exists := registeredEndpoints[svcPort]; !exists { <ins> lb.resetService(svcPort) } } } func (lb *LoadBalancerRR) resetService(svcPort proxy.ServicePortName) { // If the service is still around, reset but don't delete. if state, ok := lb.services[svcPort]; ok { if len(state.endpoints) > 0 { </ins> glog.V(2).Infof("LoadBalancerRR: Removing endpoints for %s", svcPort) <del> // Reset but don't delete. state := lb.services[svcPort] </del> state.endpoints = []string{} <del> state.index = 0 state.affinity.affinityMap = map[string]*affinityState{} </del> } <ins> state.index = 0 state.affinity.affinityMap = map[string]*affinityState{} </ins> } }
Code change:
/kind bug What happened: We constantly log message like at V(2) that don't tell any useful information.

Related discussion:
text: for portname := range portsToEndpoints { svcPort := proxy.ServicePortName{NamespacedName: types.NamespacedName{Namespace: endpoints.Namespace, Name: endpoints.Name}, Port: portname} <del> glog.V(2).Infof("LoadBalancerRR: Removing endpoints for %s", svcPort) // If the service is still around, reset but don't delete. if state, ok := lb.services[svcPort]; ok { state.endpoints = []string{} state.index = 0 state.affinity.affinityMap = map[string]*affinityState{} } </del> <ins> lb.resetService(svcPort) </ins> } }
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )

Related discussion:
text: {Type: v1.NodeMemoryPressure, Status: v1.ConditionFalse}, {Type: v1.NodeDiskPressure, Status: v1.ConditionFalse}, {Type: v1.NodeNetworkUnavailable, Status: v1.ConditionFalse}, <del> {Type: v1.NodeInodePressure, Status: v1.ConditionFalse}, </del> } return node }(),
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )

Related discussion:
text: node := newNode("node1", nil) node.Status.Conditions = []v1.NodeCondition{ {Type: v1.NodeOutOfDisk, Status: v1.ConditionTrue}, <del> {Type: v1.NodeInodePressure, Status: v1.ConditionFalse}, </del> } return node }(),
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )

Related discussion:
text: NodeDiskPressure NodeConditionType = "DiskPressure" // NodeNetworkUnavailable means that network for the node is not correctly configured. NodeNetworkUnavailable NodeConditionType = "NetworkUnavailable" <del> // NodeInodePressure means the kubelet is under pressure due to insufficient available inodes. NodeInodePressure NodeConditionType = "InodePressure" </del> ) // NodeCondition contains condition information for a node.
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )

Related discussion:
text: v1.NodeOutOfDisk, v1.NodeMemoryPressure, v1.NodeDiskPressure, <del> // We don't change 'NodeInodePressure' condition, as it'll be removed in future. // v1.NodeInodePressure, </del> // We don't change 'NodeNetworkUnavailable' condition, as it's managed on a control plane level. // v1.NodeNetworkUnavailable, }
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have a transient local disk mounted under /var/lib/docker in order to take advantage of faster IO on Azure VMs. This means that all that data is lost when a reboot occurs, but the rest of the data outside that mountpoint persists. After the reboot, the existing pods are relaunched, and kubelet is unable to create the log file symlinks because they already exist, but they are pointing to an invalid place, that container no longer exists. Here are the relevant log lines: The old symlinks are there: What you expected to happen: The correct symlinks should overwrite the old ones. How to reproduce it (as minimally and precisely as possible): Erase /var/lib/docker between reboots with existing pods. Anything else we need to know?: No. Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-30T17:46:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Azure VMs OS (e.g. from /etc/os-release): Container Linux by CoreOS 1409.6.0 (Ladybug) Kernel (e.g. ): Linux node-2-vm 4.11.9-coreos SMP Thu Jul 6 00:54:42 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I think this falls under
Reiterating the mentions to trigger a notification: <detailsIn response to : I think this falls under 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

Related discussion:
text: if realPath != "" { // Only create the symlink when container log path is specified and log file exists. <ins> // Delete possibly existing file first if err = ds.os.Remove(path); err == nil { glog.Warningf("Deleted previously existing symlink file: %q", path) } </ins> if err = ds.os.Symlink(realPath, path); err != nil { return fmt.Errorf("failed to create symbolic link %q to the container log file %q for container %q: %v", path, realPath, containerID, err)
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have a transient local disk mounted under /var/lib/docker in order to take advantage of faster IO on Azure VMs. This means that all that data is lost when a reboot occurs, but the rest of the data outside that mountpoint persists. After the reboot, the existing pods are relaunched, and kubelet is unable to create the log file symlinks because they already exist, but they are pointing to an invalid place, that container no longer exists. Here are the relevant log lines: The old symlinks are there: What you expected to happen: The correct symlinks should overwrite the old ones. How to reproduce it (as minimally and precisely as possible): Erase /var/lib/docker between reboots with existing pods. Anything else we need to know?: No. Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-30T17:46:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Azure VMs OS (e.g. from /etc/os-release): Container Linux by CoreOS 1409.6.0 (Ladybug) Kernel (e.g. ): Linux node-2-vm 4.11.9-coreos SMP Thu Jul 6 00:54:42 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I think this falls under
Reiterating the mentions to trigger a notification: <detailsIn response to : I think this falls under 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

Related discussion:
text: assert.NoError(t, err) // Verify container log symlink deletion <ins> // symlink is also tentatively deleted at startup </ins> err = ds.RemoveContainer(id) assert.NoError(t, err) <del> assert.Equal(t, fakeOS.Removes, []string{kubeletContainerLogPath}) </del> <ins> assert.Equal(t, []string{kubeletContainerLogPath, kubeletContainerLogPath}, fakeOS.Removes) </ins> } // TestContainerCreationConflict tests the logic to work around docker container
Code change:
/kind bug /sig storage
/assign
It also fails on debian GKE. However, they all pass on debian and GCI GCE. Error msg is mounting timed out. This leads me to suspect that there is some difference in networking for GKE vs GCE.
I do strongly suspect there is some networking issue on GKE. Many other tests are also failing with "connection timed out" errors. 1.7 GKE tests are looking healthy, so it seems like something is broken on master. /sig network
Fixed by /close

Related discussion:
text: if strings.Contains(cfg.Global.NetworkName, "/") { networkURL = cfg.Global.NetworkName } else { <del> networkURL = gceNetworkURL(apiEndpoint, projectID, networkName) </del> <ins> networkURL = gceNetworkURL(apiEndpoint, projectID, cfg.Global.NetworkName) </ins> } }
Code change:
/kind bug /sig storage
/assign
It also fails on debian GKE. However, they all pass on debian and GCI GCE. Error msg is mounting timed out. This leads me to suspect that there is some difference in networking for GKE vs GCE.
I do strongly suspect there is some networking issue on GKE. Many other tests are also failing with "connection timed out" errors. 1.7 GKE tests are looking healthy, so it seems like something is broken on master. /sig network
Fixed by /close

Related discussion:
text: gce := &GCECloud{ service:                  service, <ins> serviceAlpha:             serviceAlpha, </ins> serviceBeta:              serviceBeta, containerService:         containerService, cloudkmsService:          cloudkmsService,
Code change:
What happened: Wrong HPA condition - ScalingLimited have one rc with 1 replica(current have 1 pod) have one hpa with spec.minReplicas=1 and spec.maxReplicas=10 HPA condition ScalingLimited is true and described by below, I expect ScalingLimited=false at that time. What you expected to happen: I expect ScalingLimited=false at above time How to reproduce it (as minimally and precisely as possible): kubernetes with DNS api server with --runtime-config="api/all=true" binaries and images, deploy heapster, influxdb and grafana in kubernetes a rc a v2 hpa hpa conditions by I expect ScalingLimited of hpa conditions should be: Addition info:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig scalability
could you please take a look.
/sig autoscaling
It looks, at first glance, like what's happening is that since CPU usage is zero, we're calculating a desired replica count of 0, which is less that the minimum (1), so we're getting . We might want to detect this condition and provide another status message that's clearer. does that make sense on your end? Does the problem persist if CPU usage is non-zero?
Yes, the problem only persist if CPU usage is zero, and not exist when CPU usage is non-zero. I will keep this issue open if you want to improve and let it more clearer while CPU usage is zero. Thank you.
If this is still an open issue, I'd love to take a shot at submitting a pr for it. To confirm, the desired behavior is that if CPU usage is zero, and the desired replica count is 0, which is less than the minimum (1), should still be , but the status message should make it clear that it is because the CPU usage is zero?
I'd be happy to review such a PR :-). Yep! Having zero usage is a bit of a special case, so it's probably worth letting people know explicitly.
Wonderful! Working on it :)

Related discussion:
text: desiredReplicas = scaleUpLimit case hpa.Spec.MinReplicas != nil && desiredReplicas < *hpa.Spec.MinReplicas: // make sure we aren't below our minimum <del> setCondition(hpa, autoscalingv2.ScalingLimited, v1.ConditionTrue, "TooFewReplicas", "the desired replica count was less than the minimum replica count") </del> <ins> var statusMsg string if desiredReplicas == 0 { statusMsg = "the desired replica count was zero" } else { statusMsg = "the desired replica count was less than the minimum replica count" } setCondition(hpa, autoscalingv2.ScalingLimited, v1.ConditionTrue, "TooFewReplicas", statusMsg) </ins> desiredReplicas = *hpa.Spec.MinReplicas case desiredReplicas == 0: //  never scale down to 0, reserved for disabling autoscaling
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?:BUG REPORT What happened: the err message in addNamespaceRoleBinding is wrong. ref to
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig auth

Related discussion:
text: func addNamespaceRoleBinding(namespace string, roleBinding rbac.RoleBinding) { if !strings.HasPrefix(namespace, "kube-") { <del> glog.Fatalf(`roles can only be bootstrapped into reserved namespaces starting with "kube-", not %q`, namespace) </del> <ins> glog.Fatalf(`rolebindings can only be bootstrapped into reserved namespaces starting with "kube-", not %q`, namespace) </ins> } existingRoleBindings := namespaceRoleBindings[namespace]