jiebi/CodeConvo huggingface dataset:
Change:
Currently, there many error messages in that do not contain any context. This means that these messages are basically meaningless in real systems where many pods may be on a node. Examples: Every error message in this file should identify the path that the message is in relation to.
Can you handle this, since you most recently touched in ?

Discussion:
exec := exec.New() outputBytes, err := exec.Command(nsenterPath, args...).CombinedOutput() if len(outputBytes) != 0 { <del> glog.V(5).Infof("Output from mount command: %v", string(outputBytes)) </del> <ins> glog.V(5).Infof("Output of mounting %s to %s: %v", source, target, string(outputBytes)) </ins> } return err

exec := exec.New() outputBytes, err := exec.Command(nsenterPath, args...).CombinedOutput() if len(outputBytes) != 0 { <del> glog.V(5).Infof("Output from mount command: %v", string(outputBytes)) </del> <ins> glog.V(5).Infof("Output of unmounting %s: %v", target, string(outputBytes)) </ins> } return err

exec := exec.New() out, err := exec.Command(nsenterPath, args...).CombinedOutput() if err != nil { <del> glog.V(2).Infof("Failed findmnt command: %v", err) </del> <ins> glog.V(2).Infof("Failed findmnt command for path %s: %v", file, err) </ins> // Different operating systems behave differently for paths which are not mount points. // On older versions (e.g. 2.20.1) we'd get error, on newer ones (e.g. 2.26.2) we'd get "/". // It's safer to assume that it's not a mount point.

} strOut := strings.TrimSuffix(string(out), "n") <del> glog.V(5).Infof("IsLikelyNotMountPoint findmnt output: %v", strOut) </del> <ins> glog.V(5).Infof("IsLikelyNotMountPoint findmnt output for path %s: %v", file, strOut) </ins> if strOut == file { return false, nil }
Change:
gcloud at HEAD changed output of some compute list commands to print nothing to stdout, which causes to fail spuriously. Currently trying to patch a fix. cc

Discussion:
local attempt=1 local result="" while true; do <del> if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2} | grep "${GREP_REGEX}"); then </del> <ins> if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2}); then if [[ ! -z "${GREP_REGEX}" ]]; then result=$(echo "${result}" | grep "${GREP_REGEX}") fi </ins> echo "${result}" return fi
Change:
Example: I have a fixing PR ready, will send it in a moment.
/sig docs /assign closing because linked pr fixed this
/close

Discussion:
kube::log::usage_from_stdin() { local messages=() while read -r line; do <del> messages+=$line </del> <ins> messages+=("$line") </ins> done kube::log::usage "${messages[@]}"

kube::log::info_from_stdin() { local messages=() while read -r line; do <del> messages+=$line </del> <ins> messages+=("$line") </ins> done kube::log::info "${messages[@]}"

if [[ -z "$(which go)" ]]; then kube::log::usage_from_stdin <<EOF Can't find 'go' in PATH, please fix and retry. See http://golang.org/doc/install for installation instructions. EOF exit 2 fi

go_version=($(go version)) if [[ "${go_version[2]}" < "go1.4" ]]; then kube::log::usage_from_stdin <<EOF Detected go version: ${go_version[*]}. Kubernetes requires go version 1.4 or greater. Please install Go version 1.4 or later. EOF exit 2 fi
Change:
We should track how often such failures happen. cc
Thanks for filing the issue. Looks like the node stuck at downloading our binary. Here is what I found at startup script: Apr 13 14:25:48 kubemark-5-master startupscript: Downloading binary release tar () ... Anything change lately with our startup script?
I even don't know who to ask... ?
Looks like is not retrying correctly
Thanks Mike! Agree with Dawn and Mike that this looks more like a node or cluster issue than test infra.

Discussion:
for url in "${urls[@]}"; do local file="${url##*/}" rm -f "${file}" <del> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --retry 6 --retry-delay 10 "${url}"; then </del> <ins> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 80 --retry 6 --retry-delay 10 "${url}"; then </ins> echo "== Failed to download ${url}. Retrying. ==" elif [[ -n "${hash}" ]] && ! validate-hash "${file}" "${hash}"; then echo "== Hash validation of ${url} failed. Retrying. =="
Change:
This is a simple issue, no code required :) , just need to push the images/ iperf container to gcr . details merged a Dockerfile for building iperf containers. can be completed once we push to gcr. maybe you can help push the container since you reviewed the original pr ? That will allow me to do : which will finalize this iteration of the iperf network tests.
the image now exists, but produced a ton of complaints about automake-1.9 not existing on my system. Can you let me know if this was fatal (still seemed to build stuff)?
ok ill test onto my own docker repo and see
Thanks! You'll probably want to do
Ok. So, the container is working for me without building it.... so the GCR stuff is working
Super! That is what counts :)
ok ... and if we add to the Dockerfile, then it will output one-less error message, so that might be a good PR to put in. We can also upgrade to iperf3 after the iperf2 e2e runs a little while.

Discussion:
<ins> # Copyright 2016 The Kubernetes Authors All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. TAG = e2e PREFIX = gcr.io/google_containers IMAGE = iperf all: push container: image image: docker build -t $(PREFIX)/${IMAGE} . # Build new image and automatically tag it as latest docker tag $(PREFIX)/${IMAGE} $(PREFIX)/${IMAGE}:$(TAG) # Add the version tag to the latest image push: image gcloud docker push $(PREFIX)/${IMAGE} # Push image tagged as latest to repository gcloud docker push $(PREFIX)/${IMAGE}:$(TAG) # Push version tagged image to repository (since this image is already pushed it will simply create or update version tag) clean: </ins>
Change:
Ref: verify-swagger-spec is always passing on both travis and jenkins even when the swagger spec is not updated. It fails when run locally if the spec is not updated. Need to figure out why does it not fail on travis and jenkins.
It is failing now: https://travis- All I did was add some echo statements :)
Sent to fix this

Discussion:
set -o nounset set -o pipefail <ins> echo "Note: This assumes that types_swagger_doc_generated.go has been updated for all API group versions. Please run hack/update-generated-swagger-docs.sh to ensure that." </ins> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. SWAGGER_ROOT_DIR="${KUBE_ROOT}/api/swagger-spec" source "${KUBE_ROOT}/hack/lib/init.sh"

set -o nounset set -o pipefail <ins> echo "Note: This assumes that swagger spec has been updated. Please run hack/update-swagger-spec.sh to ensure that." </ins> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" kube::golang::setup_env

for group_version in "${GROUP_VERSIONS[@]}"; do generate_version "${group_version}" done <del> "${KUBE_ROOT}/hack/update-swagger-spec.sh" </del>
Change:
On my laptop running Fedora 23, this script consistently fails when networking is disabled. To reproduce: Actual results: Logs: Expected results: The apiserver launches and announces on localhost.
Resolved in my case by

Discussion:
--admission-control="${ADMISSION_CONTROL}"  --insecure-bind-address="${API_HOST}"  --insecure-port="${API_PORT}"  <ins> --advertise-address="${API_HOST}"  </ins> --etcd-servers="http://127.0.0.1:4001"  --service-cluster-ip-range="10.0.0.0/24"  --cors-allowed-origins="${API_CORS_ALLOWED_ORIGINS}" >"${APISERVER_LOG}" 2>&1 &
Change:
I noticed that httpHeaders were to the httpGet probe in to Sadly the httpHeaders addition to the httpGet probe does function correctly for all headers except the header. I think this must be to do with the way make a special case of the Host header . I have some code I used to debug the issue that I can share if needed.
Sigh, letting you set Host was the entire point of providing that option.
Does the host header work in probes now? I have been browsing the issues but can not tell, as I am having trouble with it in my setup.
my fix should be in kubernetes 1.2.3+ I found some code that exercises the issue... could you try this on your cluster I cannot reproduce in the environment I have to hand that is running k8s 1.7

Discussion:
return probe.Failure, err.Error(), nil } req.Header = headers <ins> if headers.Get("Host") != "" { req.Host = headers.Get("Host") } </ins> res, err := client.Do(req) if err != nil { // Convert errors into failures to catch timeouts.

}, }, { <ins> // Echo handler that returns the contents of Host in the body func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) w.Write([]byte(r.Host)) }, http.Header{ "Host": {"muffins.cupcakes.org"}, }, probe.Success, []string{ "muffins.cupcakes.org", }, }, { </ins> handleReq(FailureCode, "fail body"), nil, probe.Failure,
Change:
Looks like it maybe the ssh connect is getting killed
The relevant log snippet:
And another one, not just coreos.

Discussion:
func (lr *LogReporter) SpecSuiteWillBegin(config config.GinkgoConfigType, summary *types.SuiteSummary) { b := &bytes.Buffer{} b.WriteString("******************************************************n") <del> glog.V(2).Infof(b.String()) </del> <ins> glog.V(0).Infof(b.String()) </ins> } func (lr *LogReporter) BeforeSuiteDidRun(setupSummary *types.SetupSummary) {}

b.WriteString(fmt.Sprintf("etcd output:n%sn", e2es.etcdCombinedOut.String())) } b.WriteString("******************************************************n") <del> glog.V(2).Infof(b.String()) </del> <ins> glog.V(0).Infof(b.String()) </ins> }

go func() { err := cmd.Run() if err != nil { <del> cmdErrorChan <- fmt.Errorf("%s Exited with status %v.  Output:n%v", cmd, err, *cmd.OutputBuffer) </del> <ins> cmdErrorChan <- fmt.Errorf("%s Failed with error "%v".  Command output:n%s", cmd, err, *cmd.OutputBuffer) </ins> } close(cmdErrorChan) }()

fmt.Printf("Initializing e2e tests using host %s.n", host) running++ go func(host string) { <del> results <- testHost(host, archive) </del> <ins> results <- testHost(host, archive, *cleanup) </ins> }(host) } }

} // Run tests in archive against host <del> func testHost(host, archive string) *TestResult { output, err := e2e_node.RunRemote(archive, host, *cleanup) </del> <ins> func testHost(host, archive string, deleteFiles bool) *TestResult { output, err := e2e_node.RunRemote(archive, host, deleteFiles) </ins> return &TestResult{ output: output, err:    err,

err: fmt.Errorf("Unable to create gce instance with running docker daemon for image %s.  %v", image, err), } } <del> return testHost(host, archive) </del> <ins> return testHost(host, archive, false) </ins> } // Provision a gce instance using image
Change:
The scenario that presented a problem was the following: a) create pods in a namespace that do not make a memory claim b) add a quota that tracks memory c) update one of the pods previously created by reducing its active deadline. Expected result: Since a pod cannot change its resources via update, we should have been allowed to update the pod spec. Actual Result: error since the pod did not make a memory claim, quota rejects the pod.
cc

Discussion:
InternalGroupKind: api.Kind("Pod"), InternalOperationResources: map[admission.Operation][]api.ResourceName{ admission.Create: allResources, <del> admission.Update: computeResources, </del> <ins> // TODO: the quota system can only charge for deltas on compute resources when pods support updates. // admission.Update: computeResources, </ins> }, GetFuncByNamespace: func(namespace, name string) (runtime.Object, error) { return kubeClient.Core().Pods(namespace).Get(name)

pod := newTestPodForQuota(podName, requests, api.ResourceList{}) pod, err = f.Client.Pods(f.Namespace.Name).Create(pod) Expect(err).NotTo(HaveOccurred()) <ins> podToUpdate := pod </ins> By("Ensuring ResourceQuota status captures the pod usage") usedResources[api.ResourceQuotas] = resource.MustParse("1")

pod, err = f.Client.Pods(f.Namespace.Name).Create(pod) Expect(err).To(HaveOccurred()) <ins> By("Ensuring a pod cannot update its resource requirements") // a pod cannot dynamically update its resource requirements. requests = api.ResourceList{} requests[api.ResourceCPU] = resource.MustParse("100m") requests[api.ResourceMemory] = resource.MustParse("100Mi") podToUpdate.Spec.Containers[0].Resources.Requests = requests _, err = f.Client.Pods(f.Namespace.Name).Update(podToUpdate) Expect(err).To(HaveOccurred()) By("Ensuring attempts to update pod resource requirements did not change quota usage") err = waitForResourceQuota(f.Client, f.Namespace.Name, quotaName, usedResources) Expect(err).NotTo(HaveOccurred()) </ins> By("Deleting the pod") err = f.Client.Pods(f.Namespace.Name).Delete(podName, api.NewDeleteOptions(0)) Expect(err).NotTo(HaveOccurred())
Change:
The has to the Google L7 load balancer controller.
+1 on merging that PR, looks good.
LGTM'd the pr

Discussion:
# GCE Load-Balancer Controller (GLBC) Cluster Addon This cluster addon is composed of: <del> * A [Google L7 LoadBalancer Controller](https://github.com/kubernetes/contrib/tree/master/Ingress/controllers/gce) </del> <ins> * A [Google L7 LoadBalancer Controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce) </ins> * A [404 default backend](https://github.com/kubernetes/contrib/tree/master/404-server) Service + RC It relies on the [Ingress resource](../../../../docs/user-guide/ingress.md) only available in Kubernetes version 1.1 and beyond.
Change:
and show that we run this job every few minutes, but it never passes. I'm going to send out a PR to disable this job until someone has the time to investigate and resolve.
It's failing before tests even start:
At this point I don't think it's a flake, we needed flannel for a release and it's less important now so I'm not investigating why the cluster isn't coming up soon. I do believe if the cluster comes up a majority if not all of the tests will pass, and the ones that don't will flake for known reasons.

Discussion:
bash -c "${common_commands}" diff -ruN "${output_dir}/upstream" "${output_dir}/patch" >"${diff_file}" || true <ins> if [[ -t 1 ]]; then  # Attached to a terminal? less "${diff_file}" fi </ins> echo echo "  *** Diff saved in ${diff_file} ***"

export FAIL_ON_GCP_RESOURCE_LEAK="false" - 'gce-flannel': description: 'Run E2E tests on GCE using Flannel and the latest successful build. This suite is quarantined in a dedicated project because Flannel integration is experimental.' <ins> disable_job: true  # Issue #24520 </ins> # We don't really care to enforce a timeout for flannel tests. Any performance issues will show up in the other GCE builders. # This suite is to continuously check that flannel + Kubernetes works. timeout: 120
Change:
It failed in cc
I have some hypothesis. But I need to verify it. I will submit something to print more info in the test.
and others referencing this Please share links to unit test logs
We are able to reproduce this locally and confirm the failure: Submitted to fix it.
For a concrete reason why the test failed: That specific sequence is kinda non-blocking because the object is filtered. It calls Stop() really fast and cancel context. sync() returns context.Canceled

Discussion:
func testCheckStop(t *testing.T, i int, w watch.Interface) { select { <del> case _, ok := <-w.ResultChan(): </del> <ins> case e, ok := <-w.ResultChan(): </ins> if ok { <del> t.Errorf("#%d: ResultChan should have been closed", i) </del> <ins> var obj string switch e.Object.(type) { case *api.Pod: obj = e.Object.(*api.Pod).Name case *unversioned.Status: obj = e.Object.(*unversioned.Status).Message } t.Errorf("#%d: ResultChan should have been closed. Event: %s. Object: %s", i, e.Type, obj) </ins> } case <-time.After(wait.ForeverTestTimeout): t.Errorf("#%d: time out after waiting 1s on ResultChan", i)
Change:
Perhaps a bug in
Thanks for catching this! I'm surprised it wasn't noticed earlier. It's an off by 1 (s) error. We pushed to gs://kubernetes-releases vs gs://kubernetes-release. The offending s has been removed. I'll clean up the release itself.
I thought this was right, but I think this is still an issue. I'm trying to release , and it's building wrong. I guess there were actually two problems; you caught one, but not the one I meant. This issue was about: should report itself as , but instead it reports itself as .
I'll look into this, since it's blocking alpha releases.
This seems contrary to , but doesn't have enough context for me to know why it was changed.
This was fixed by a long time ago.

Discussion:
binary | sha1 hash | md5 hash ------ | --------- | -------- <del> [kubernetes.tar.gz](https://storage.googleapis.com/kubernetes-releases/release/v1.3.0-alpha.2/kubernetes.tar.gz) | `305c8c2af7e99d463dbbe4208ecfe2b50585e796` | `aadb8d729d855e69212008f8fda628c0` </del> <ins> [kubernetes.tar.gz](https://storage.googleapis.com/kubernetes-release/release/v1.3.0-alpha.2/kubernetes.tar.gz) | `305c8c2af7e99d463dbbe4208ecfe2b50585e796` | `aadb8d729d855e69212008f8fda628c0` </ins> ## Changes since v1.3.0-alpha.1
Change:
I've run to create a cluster, which resulted in a cluster and user being created in kube-config. Now I want to run again with different parameters, to create a second cluster in a different AWS account. I would like to use a different name for the cluster and user for this cluster. From what I can see from the , there seems to be no way to completely override the name used. I understand that I can use a separate kube-config file, but I don't want to do that. I want to use the same kube-config file, with multiple clusters and users, all handled by .
Manually overwriting file to set CONTEXT to a different value works to achieve the effect that I want. This value should be allowed to be set externally so that we don't have to resort to manually editing the file for each cluster.
Fixed in

Discussion:
INSTANCE_PREFIX="${KUBE_AWS_INSTANCE_PREFIX:-kubernetes}" CLUSTER_ID=${INSTANCE_PREFIX} AWS_SSH_KEY=${AWS_SSH_KEY:-$HOME/.ssh/kube_aws_rsa} <ins> CONFIG_CONTEXT="${KUBE_CONFIG_CONTEXT:-aws_${INSTANCE_PREFIX}}" </ins> IAM_PROFILE_MASTER="kubernetes-master" IAM_PROFILE_NODE="kubernetes-minion"

EXTRA_DOCKER_OPTS="${EXTRA_DOCKER_OPTS:-}" INSTANCE_PREFIX="${KUBE_AWS_INSTANCE_PREFIX:-e2e-test-${USER}}" <ins> CONFIG_CONTEXT="${KUBE_CONFIG_CONTEXT:-aws_${INSTANCE_PREFIX}}" </ins> CLUSTER_ID=${INSTANCE_PREFIX} AWS_SSH_KEY=${AWS_SSH_KEY:-$HOME/.ssh/kube_aws_rsa} IAM_PROFILE_MASTER="kubernetes-master"

export KUBE_CERT="${CERT_DIR}/pki/issued/kubecfg.crt" export KUBE_KEY="${CERT_DIR}/pki/private/kubecfg.key" export CA_CERT="${CERT_DIR}/pki/ca.crt" <del> export CONTEXT="aws_${INSTANCE_PREFIX}" </del> <ins> export CONTEXT="${CONFIG_CONTEXT}" </ins> ( umask 077 create-kubeconfig
Change:
The panic is bad but I would expect the command to return to me valid outputs I could use and error out. we should also make sure the nil dereference in the resource printer gets handled. Your PR justs masks it.
Btw, I didn't make up the empty string on purpose. It was documented in the output and it was seen as the default setting of . So perhaps someone should also fix the help text so newbies like me don't cause crashes as easily? Thanks.
I'd expect that we validate what's provided to and print the valid options if something unexpected was provided (including blank string). But the way we print flags that expect strings (and defaults to empty) in help can lead to this kind of confusion and other issues (on Windows, for example). A few ideas: pflag could have a "select" type that takes a list of valid options (and validates/throws errors automatically).
Agreed with that the current way of showing flags in the help is not optimal. cc:
I did agree that panic is bad, we should avoid this. The problem is if a user did use an empty output, how to handle this more properly. In PR you commented that we should not override user settings, it seems we should error out directly in this situation. Besides, nil dereference in the resource printer should be handled, will add this.

Discussion:
fmt.Printf("--output wide is not available in kubectl config view; reset to default output format (%s)nn", defaultOutputFormat) cmd.Flags().Set("output", defaultOutputFormat) } <ins> if outputFormat == "" { fmt.Printf("reset to default output format (%s) as --output is empty", defaultOutputFormat) cmd.Flags().Set("output", defaultOutputFormat) } </ins> printer, _, err := cmdutil.PrinterForCommand(cmd) cmdutil.CheckErr(err)
Change:
Not much info on why or how it failed. cc
Cc On Apr 28, 2016 5:08 PM, "Mike Danese" wrote:
cc
cant open the link, would you mind paste the content?
can you access http://ci- ?
It failed due to bind address already in use. The same address were used in example/apiserver (which runs befor federated-apiserver) as well. I wonder if the tests are run in parallel? If it is the case, I can change the port to other values (8082 for example) Otherwise, it may indicate that the address:port was not proper released for some reason
Yes, tests run in parallel. Can you perhaps use a random port number each time? This will reduce the probability of collision to nearly zero (close enough to zero for practical purposes). See . also provides other background reading, but is focussed on end-to-end tests. Much of the discussion applies to unit tests also though.
I think changing the Insecure Port at from 8081 to some other value (say, 8082) should be fine.
Which should I use? 8082 or random? Personally I wouldn't be so optimistic about using random port number since no matter how small the probability is, it will happen eventually, which would be a surprise to those who's not aware of this.
Yes I am fine with changing the port to 8082. Feel free to send me the PR for review.
If you specify port 0 when you bind, the kernel will hand you an available port so there won't be a conflict.
We also want to know the port to be able to curl it in the test.

Discussion:
} } <del> var insecurePort = 8081 </del> <ins> var insecurePort = 8082 </ins> var serverIP = fmt.Sprintf("http://localhost:%v", insecurePort) var groupVersion = fed_v1a1.SchemeGroupVersion
Change:
I can reproduce it every time. and /cc
It show passes when doing this patch:
I do not know the detail, but it looks like the test actually report error at line 77 and not 78.
What go version are you using?
If I remember correctly, it could be reproduced when running with go1.5.3 and go1.6.1. To be more specific, the go test passes, and this issue only happened when enabled with .
Interesting. I guess code coverage changes the behavior of line reporting? I'm willing to take a PR to fix this!
the coverage tool rewrites source code. Seems like a bug that it changes line numbers in the files. Skipping it wasn't the right fix IMO, we should file a bug with them.
Closing due to age, reopen if this is re-creatable.

Discussion:
# must make sure the output from parallel runs is not mixed. To achieve this, # we spawn a subshell for each parallel process, redirecting the output to # separate files. <del> printf "%sn" "${@}" | xargs -I{} -n1 -P${KUBE_COVERPROCS}  </del> <ins> # cmd/libs/go2idl/generator is fragile when run under coverage, so ignore it for now. # see: https://github.com/kubernetes/kubernetes/issues/24967 printf "%sn" "${@}" | grep -v "cmd/libs/go2idl/generator"| xargs -I{} -n1 -P${KUBE_COVERPROCS}  </ins> bash -c "set -o pipefail; _pkg="{}"; _pkg_out=${_pkg////_};  go test ${goflags[@]:+${goflags[@]}}  ${KUBE_RACE}