jiebi/CodeConvo huggingface dataset:
Code change:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .

Related discussion:
text: exit 1 fi <ins> do_backup_clean </ins> # use an array to record name and ip declare -A mm
Code change:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .

Related discussion:
text: inList $etcdName $myIP configEtcd $etcdName $myIP $cluster # For minion set MINION IP in default_scripts/kubelet <del> sed -i "s/MY_IP/${myIP}/g" default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" default_scripts/kube-proxy </del> <ins> sed -i "s/MY_IP/${myIP}/g" work/default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" work/default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" work/default_scripts/kube-proxy </ins> # For master set MINION IPs in kube-controller-manager <del> if [ -z "$minionIPs" ]; then </del> <ins> if [ -z "$minionIPs" ]; then </ins> #one node act as both minion and master role minionIPs="$myIP" else minionIPs="$minionIPs,$myIP" fi <del> sed -i "s/MINION_IPS/${minionIPs}/g" default_scripts/kube-controller-manager </del> <ins> sed -i "s/MINION_IPS/${minionIPs}/g" work/default_scripts/kube-controller-manager </ins> cpMaster cpMinion
Code change:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .

Related discussion:
text: inList $etcdName $myIP configEtcd $etcdName $myIP $cluster # set MINION IPs in kube-controller-manager <del> sed -i "s/MINION_IPS/${minionIPs}/g" default_scripts/kube-controller-manager </del> <ins> sed -i "s/MINION_IPS/${minionIPs}/g" work/default_scripts/kube-controller-manager </ins> cpMaster break ;;
Code change:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .

Related discussion:
text: inList $etcdName $myIP configEtcd $etcdName $myIP $cluster # set MINION IP in default_scripts/kubelet <del> sed -i "s/MY_IP/${myIP}/g" default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" default_scripts/kube-proxy </del> <ins> sed -i "s/MY_IP/${myIP}/g" work/default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" work/default_scripts/kubelet sed -i "s/MASTER_IP/${masterIP}/g" work/default_scripts/kube-proxy </ins> cpMinion break ;;
Code change:
After 6 minutes or so of using 50% my 4-core MBP CPU and chewing up a ton of memory, make release gives up with a timeout.
This is on my master branch (no local changes) after rebasing to head this evening. It was working fine earlier today so seems like the likely culprit. /cc
It's certainly my changes. I'm on a low function device, feel free to revert. This is only an issue for low memory systems, I suspect. :/ On Apr 1, 2015 10:24 PM, "Robert Bailey" wrote:
(This is functioning fine on Jenkins and my desktop, FWIW.) On Apr 1, 2015 10:36 PM, "Zachary Loafman" wrote:

Related discussion:
text: # Find all of the built client binaries local platform platforms platforms=($(cd "${LOCAL_OUTPUT_BINPATH}" ; echo */*)) <del> for platform in "${platforms[@]}"; do </del> <ins> for platform in "${platforms[@]}" ; do </ins> local platform_tag=${platform///-} # Replace a "/" for a "-" <del> kube::log::status "Starting tarball: client $platform_tag" </del> <ins> kube::log::status "Building tarball: client $platform_tag" </ins> <del> ( local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </del> <ins> local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </ins> <del> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </del> <ins> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </ins> <del> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </del> <ins> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </ins> <del> kube::release::clean_cruft </del> <ins> kube::release::clean_cruft </ins> <del> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." ) & </del> <ins> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." </ins> done <del> kube::log::status "Waiting on tarballs" wait || { kube::log::error "client tarball creation failed"; exit 1; } </del> } # Package up all of the server binaries
Code change:
Restarting might also be acceptable. It's a pretty painful user experience right now if this happens-- it fills the logs with this message.
Yes, it should just panic() , Daniel Smith wrote:
Yeah I guess if it's out of FDs it can't really open a network connection to file an event...
kube-proxy should send an event when it starts up, just like kubelet does with its method. This works around the fact that you can't send an event when you are out of FDs, and it still provides a lot of debugging value.
Agreed with 1) kube-proxy should panic when hitting out of fd 2) restarted kube-proxy should pick up the crash reason like what we do for internal agent 3) crash reason should be propogated to upstream as an event.
Moving to the right sig.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
/remove-lifecycle stale
/area kube-proxy
we're going to close this because, after 3 years or so , decreasing interest in the userspace proxy and nobody other then some openshift folks, are using the linux kube proxy .. can reopen if necessary ping :)
/close
Closing this issue. <detailsIn response to : /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

Related discussion:
text: // and keep accepting inbound traffic. outConn, err := net.DialTimeout(protocol, endpoint, retryTimeout*time.Second) if err != nil { <ins> if isTooManyFDsError(err) { panic("Dial failed: " + err.Error()) } </ins> glog.Errorf("Dial failed: %v", err) continue }
Code change:
Restarting might also be acceptable. It's a pretty painful user experience right now if this happens-- it fills the logs with this message.
Yes, it should just panic() , Daniel Smith wrote:
Yeah I guess if it's out of FDs it can't really open a network connection to file an event...
kube-proxy should send an event when it starts up, just like kubelet does with its method. This works around the fact that you can't send an event when you are out of FDs, and it still provides a lot of debugging value.
Agreed with 1) kube-proxy should panic when hitting out of fd 2) restarted kube-proxy should pick up the crash reason like what we do for internal agent 3) crash reason should be propogated to upstream as an event.
Moving to the right sig.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
/remove-lifecycle stale
/area kube-proxy
we're going to close this because, after 3 years or so , decreasing interest in the userspace proxy and nobody other then some openshift folks, are using the linux kube proxy .. can reopen if necessary ping :)
/close
Closing this issue. <detailsIn response to : /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

Related discussion:
text: // Then the service port was just closed so the accept failure is to be expected. break } <ins> if isTooManyFDsError(err) { panic("Accept failed: " + err.Error()) } </ins> glog.Errorf("Accept failed: %v", err) continue }
Code change:
Restarting might also be acceptable. It's a pretty painful user experience right now if this happens-- it fills the logs with this message.
Yes, it should just panic() , Daniel Smith wrote:
Yeah I guess if it's out of FDs it can't really open a network connection to file an event...
kube-proxy should send an event when it starts up, just like kubelet does with its method. This works around the fact that you can't send an event when you are out of FDs, and it still provides a lot of debugging value.
Agreed with 1) kube-proxy should panic when hitting out of fd 2) restarted kube-proxy should pick up the crash reason like what we do for internal agent 3) crash reason should be propogated to upstream as an event.
Moving to the right sig.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
/remove-lifecycle stale
/area kube-proxy
we're going to close this because, after 3 years or so , decreasing interest in the userspace proxy and nobody other then some openshift folks, are using the linux kube proxy .. can reopen if necessary ping :)
/close
Closing this issue. <detailsIn response to : /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

Related discussion:
text: args = append(args, "-j", "DNAT", "--to-destination", net.JoinHostPort(proxyIP.String(), strconv.Itoa(proxyPort))) return args } <ins> func isTooManyFDsError(err error) bool { return strings.Contains(err.Error(), "too many open files") } </ins>
Code change:
kubernetes]$ make hack/build- Detected go version: go version devel + Wed Mar 4 20:55:55 2015 +0000 linux/amd64.Kubernetes requires go version 1.2 or greater.Please install Go version 1.2 or later. !!! Error in 'kube::golang::buildbinaries "$ exited with status 2 Call stack: 1: kube::golang::buildbinaries(...) 2: hack/build- main(...) Exiting with status 1 make: * [all] Error 1
Hello, it would be really nice feature to have and it seems easy to fix/implement. Are there any plans on fixing the build?

Related discussion:
text: if [[ "${TRAVIS:-}" != "true" ]]; then local go_version go_version=($(go version)) <del> if [[ "${go_version[2]}" < "go1.6" ]]; then </del> <ins> if [[ "${go_version[2]}" < "go1.6" && "${go_version[2]}" != "devel" ]]; then </ins> kube::log::usage_from_stdin <<EOF Detected go version: ${go_version[*]}. Kubernetes requires go version 1.6 or greater.
Code change:
The master sets its endpoints into the 'kubernetes' service, but endpoints can only be IPv4 today. So ChooseHostInterface() should either not return an IPv6 address, or we should allow endpoints to be IPv6.
I think that this is likely the cause of .
I thought that function explicitly checked for v4. got any bandwidth for review? On May 4, 2015 11:24 AM, "Robert Bailey" wrote:
It doesn't - and on my mac, it fails to find this address when I add that logic. Not sure if that's FlagPointToPoint or something: ----- Original Message -----
PEBKAC for the issue I mentioned above, is opened to fix the choice.
Yeah, I can take a look at later this afternoon, just as soon as I've unbroken ELB's :-) smarterclayton@ let me know if is more urgent than that.
was smaller than I thought, so committed priority inversion I reviewed it :-)

Related discussion:
text: return nil, err } i := 0 <ins> var ip net.IP </ins> for i = range intfs { if flagsSet(intfs[i].Flags, net.FlagUp) && flagsClear(intfs[i].Flags, net.FlagLoopback|net.FlagPointToPoint) { addrs, err := intfs[i].Addrs()
Code change:
The master sets its endpoints into the 'kubernetes' service, but endpoints can only be IPv4 today. So ChooseHostInterface() should either not return an IPv6 address, or we should allow endpoints to be IPv6.
I think that this is likely the cause of .
I thought that function explicitly checked for v4. got any bandwidth for review? On May 4, 2015 11:24 AM, "Robert Bailey" wrote:
It doesn't - and on my mac, it fails to find this address when I add that logic. Not sure if that's FlagPointToPoint or something: ----- Original Message -----
PEBKAC for the issue I mentioned above, is opened to fix the choice.
Yeah, I can take a look at later this afternoon, just as soon as I've unbroken ELB's :-) smarterclayton@ let me know if is more urgent than that.
was smaller than I thought, so committed priority inversion I reviewed it :-)

Related discussion:
text: return nil, err } if len(addrs) > 0 { <del> // This interface should suffice. break </del> <ins> for _, addr := range addrs { if addrIP, _, err := net.ParseCIDR(addr.String()); err == nil { if addrIP.To4() != nil { ip = addrIP.To4() break } } } if ip != nil { // This interface should suffice. break } </ins> } } } <del> if i == len(intfs) { return nil, err </del> <ins> if ip == nil { return nil, fmt.Errorf("no acceptable interface from host") </ins> } glog.V(4).Infof("Choosing interface %s for from-host portals", intfs[i].Name) <del> addrs, err := intfs[i].Addrs() if err != nil { return nil, err } glog.V(4).Infof("Interface %s = %s", intfs[i].Name, addrs[0].String()) ip, _, err := net.ParseCIDR(addrs[0].String()) if err != nil { return nil, err } </del> return ip, nil }
Code change:
This page: Links to this YAML: Which doesn't exist. There are several examples now in the NFS folder:
Thanks for reporting! Always happy to get docs up-to-date, especially to reduce friction. Please report / open PRs for any others. Also, if the examples / explanations aren't clear, we're happy to address issues for that as well.

Related discussion:
text: ``` ### NFS <del> Kubernetes NFS volumes allow an existing NFS share to be made available to containers within a pod. </del> <ins> Kubernetes NFS volumes allow an existing NFS share to be made available to containers within a pod. </ins> <del> [The NFS Pod example](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/nfs/test.yaml) demonstrates how to specify the usage of an NFS volume within a pod. In this example one can see that a volumeMount called "myshare" is being mounted onto /var/www/html/mount-test in the container "testpd". The volume "myshare" is defined as type nfs, with the NFS server serving from 172.17.0.2 and exporting directory /tmp as the share. The mount being created in this example is not read only. </del> <ins> See the [NFS Pod examples](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/nfs/) section for more details. For example, [nfs-web-pod.yaml](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/nfs/nfs-web-pod.yaml) demonstrates how to specify the usage of an NFS volume within a pod. In this example one can see that a `volumeMount` called "nfs" is being mounted onto `/var/www/html` in the container "web". The volume "nfs" is defined as type `nfs`, with the NFS server serving from `nfs-server.default.kube.local` and exporting directory `/` as the share. The mount being created in this example is not read only. </ins>
Code change:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

Related discussion:
text: ### SEE ALSO * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager <del> ###### Auto generated by spf13/cobra at 2015-05-28 22:43:52.329286408 +0000 UTC </del> <ins> ###### Auto generated by spf13/cobra at 2015-05-29 22:39:51.164275749 +0000 UTC </ins> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/kubectl_get.md?pixel)]()
Code change:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

Related discussion:
text: .PP Possible resources include pods (po), replication controllers (rc), services (svc), nodes, events (ev), component statuses (cs), limit ranges (limits), <del> minions (mi), persistent volumes (pv), persistent volume claims (pvc) </del> <ins> nodes (no), persistent volumes (pv), persistent volume claims (pvc) </ins> or resource quotas (quota). .PP
Code change:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

Related discussion:
text: -s "http://127.0.0.1:${API_PORT}" --match-server-version ) <del> [ "$(kubectl get minions -t '{{ .apiVersion }}' "${kube_flags[@]}")" == "v1beta3" ] </del> <ins> [ "$(kubectl get nodes -t '{{ .apiVersion }}' "${kube_flags[@]}")" == "v1beta3" ] </ins> else kube_flags=( -s "http://127.0.0.1:${API_PORT}" --match-server-version --api-version="${version}" ) <del> [ "$(kubectl get minions -t '{{ .apiVersion }}' "${kube_flags[@]}")" == "${version}" ] </del> <ins> [ "$(kubectl get nodes -t '{{ .apiVersion }}' "${kube_flags[@]}")" == "${version}" ] </ins> fi id_field=".metadata.name" labels_field=".metadata.labels"
Code change:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

Related discussion:
text: ########### <del> # Minions # </del> <ins> # Nodes # </ins> ########### if [[ "${version}" = "v1beta1" ]] || [[ "${version}" = "v1beta2" ]]; then <del> kube::log::status "Testing kubectl(${version}:minions)" </del> <ins> kube::log::status "Testing kubectl(${version}:nodes)" </ins> <del> kube::test::get_object_assert minions "{{range.items}}{{$id_field}}:{{end}}" '127.0.0.1:' </del> <ins> kube::test::get_object_assert nodes "{{range.items}}{{$id_field}}:{{end}}" '127.0.0.1:' </ins> <del> # TODO: I should be a MinionList instead of List kube::test::get_object_assert minions '{{.kind}}' 'List' </del> <ins> kube::test::get_object_assert nodes '{{.kind}}' 'List' </ins> <del> kube::test::describe_object_assert minions "127.0.0.1" "Name:" "Conditions:" "Addresses:" "Capacity:" "Pods:" </del> <ins> kube::test::describe_object_assert nodes "127.0.0.1" "Name:" "Conditions:" "Addresses:" "Capacity:" "Pods:" </ins> fi
Code change:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

Related discussion:
text: Possible resources include pods (po), replication controllers (rc), services (svc), nodes, events (ev), component statuses (cs), limit ranges (limits), <del> minions (mi), persistent volumes (pv), persistent volume claims (pvc) </del> <ins> nodes (no), persistent volumes (pv), persistent volume claims (pvc) </ins> or resource quotas (quota). By specifying the output as 'template' and providing a Go template as the value