jiebi/CodeConvo huggingface dataset:
Change:
I an ELB to the Kibana cluster log viewer but it is not reported by which, aside from having a URL, should check each cluster service and if it has an external IP it should report that instead of the master proxy address.
cc

Discussion:
"fmt" "io" "os" <ins> "strconv" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" cmdutil "github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/cmd/util"

b.Do().Visit(func(r *resource.Info) error { services := r.Object.(*api.ServiceList).Items for _, service := range services { <del> link := client.Host + "/api/v1beta3/proxy/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name </del> <ins> var link string if len(service.Spec.PublicIPs) > 0 { for _, port := range service.Spec.Ports { link += "http://" + service.Spec.PublicIPs[0] + ":" + strconv.Itoa(port.Port) + " " } } else { link = client.Host + "/api/v1beta3/proxy/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name } </ins> printService(out, service.ObjectMeta.Labels["name"], link) } return nil
Change:
After I created a persistent volume, it throws an error on "describe".
Thanks for reporting this. will fix this nil pointer bug. The problem is your volume is not yet bound, but the command line wants to show you some info from the bound claim, except there isn't one.
do you want to break out as a separate pr to fix this, since the nil deref sort of a standalone bug?
done. .

Discussion:
fmt.Fprintf(out, "Name:t%sn", pv.Name) fmt.Fprintf(out, "Labels:t%sn", formatLabels(pv.Labels)) fmt.Fprintf(out, "Status:t%dn", pv.Status.Phase) <del> fmt.Fprintf(out, "Claim:t%dn", pv.Spec.ClaimRef.UID) </del> <ins> if pv.Spec.ClaimRef != nil { fmt.Fprintf(out, "Claim:t%dn", pv.Spec.ClaimRef.Namespace+"/"+pv.Spec.ClaimRef.Name) } else { fmt.Fprintf(out, "Claim:t%dn", "") } </ins> return nil }) }
Change:
I'm trying to start 100-node cluster. I got the following error in kubelet: E0505 08:31:55. 5066 ] Failed to create kubelet: failed to initialize image manager: failed to start image manager: dial unix connection refused After ssh-ing I checked that docker is working by running . I guess it must be some kind of a race where kubelet starts before docker is ready. When I start 3-node cluster it works just fine. This happened to me 3 times in a row. Please add this to 1.0 milestone if necessary.
I've just exactly the same problem (when creating a 100-node cluster)
This is a bug in our initialization logical. We initialize image manager which needs to talk to docker at very early stage before docker is up yet. Later kubelet does a wait to make sure docker is up. We should either delay the initialization of image manager or handle docker unavailable better. Kubelet will be restarted by monit eventually, but this definitely slow down node initialization. I mark this for 1.0. Should be a simple fix if we just simply delay the initialization of image manager.
I'll go ahead and fix it (since I am mainly to blame :) )
Changed to P0 because asked us to only add P0 issues to v1.0 milestone.

Discussion:
// enough space as per the garbage collection policy. GarbageCollect() error <ins> // Start async garbage collection of images. Start() error </ins> // TODO(vmarmol): Have this subsume pulls as well. }

nodeRef:      nodeRef, } <del> err := im.start() if err != nil { return nil, fmt.Errorf("failed to start image manager: %v", err) } </del> return im, nil } <del> func (im *realImageManager) start() error { </del> <ins> func (im *realImageManager) Start() error { </ins> // Initial detection make detected time "unknown" in the past. var zero time.Time err := im.detectImages(zero)

glog.Infof("Running in container %q", kl.resourceContainer) } <ins> err := kl.imageManager.Start() if err != nil { kl.recorder.Eventf(kl.nodeRef, "imageManagerFailed", "Failed to start ImageManager %v", err) glog.Errorf("Failed to start ImageManager, images may not be garbage collected: %v", err) } </ins> go kl.syncNodeStatus() // Run the system oom watcher forever. go util.Until(kl.runOOMWatcher, time.Second, util.NeverStop)
Change:
This happened on 5/6/2015 at 07:49 am on our continuous integration system, against upstream/master head at that time (i.e. last commit ). Needs to be repro'd and debugged. Docker Containers should be able to override the image's default command and arguments Failed to create pod: Pod "client-containers--f401-11e4-9118-" is forbidden: Post http://127.0.0.1:8080/api/v1beta3/namespaces: EOF
This test is still flaky. Containers should be able to override the image's default commmand (docker entrypoint) (Failed 2 times in the last 30 runs. Stability: 93 % Containers should be able to override the image's default arguments (docker cmd) (Failed 1 times in the last 30 runs. Stability: 96 %)
I will take a look at this now
Sample log from failure:
The indicates two things 1) that the test only tried once to fetch the logs, and 2) that either the call returned an empty log or an error (which it looks like the test does not check for). See

Discussion:
// Sometimes the actual containers take a second to get started, try to get logs for 60s for time.Now().Sub(start) < (60 * time.Second) { <ins> err = nil </ins> logs, err = c.Get(). Prefix("proxy"). Resource("nodes").

Suffix("containerLogs", ns, podStatus.Name, containerName). Do(). Raw() <del> fmt.Sprintf("pod logs:%vn", string(logs)) By(fmt.Sprintf("pod logs:%vn", string(logs))) if strings.Contains(string(logs), "Internal Error") { By(fmt.Sprintf("Failed to get logs from node %q pod %q container %q: %v", podStatus.Spec.NodeName, podStatus.Name, containerName, string(logs))) </del> <ins> if err == nil && strings.Contains(string(logs), "Internal Error") { err = fmt.Errorf("Fetched log contains "Internal Error": %q.", string(logs)) } if err != nil { By(fmt.Sprintf("Warning: Failed to get logs from node %q pod %q container %q. %v", podStatus.Spec.NodeName, podStatus.Name, containerName, err)) </ins> time.Sleep(5 * time.Second) continue } <ins> By(fmt.Sprintf("Succesfully fetched pod logs:%vn", string(logs))) </ins> break }
Change:
Minor issues with 1) The examples rely on cloud vendor specific variables ($private_ipv4 ) 2) The wget command for kube-register always re-downloads

Discussion:
-e MIRROR_TAGS_CACHE_TTL=1800  quay.io/devops/docker-registry:latest - name: docker.service <ins> content: | [Unit] Description=Docker Application Container Engine Documentation=http://docs.docker.com After=docker.socket early-docker.target network.target Requires=docker.socket early-docker.target [Service] Environment=TMPDIR=/var/tmp EnvironmentFile=-/run/flannel_docker_opts.env EnvironmentFile=/etc/network-environment MountFlags=slave LimitNOFILE=1048576 LimitNPROC=1048576 ExecStart=/usr/lib/coreos/dockerd --daemon --host=fd:// --registry-mirror=http://${DEFAULT_IPV4}:5000 $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPT_IPMASQ [Install] WantedBy=multi-user.target </ins> drop-ins: - name: 51-docker-mirror.conf content: |

# startup, otherwise containers won't land in flannel's network... Requires=docker-cache.service flanneld.service After=docker-cache.service flanneld.service <del> [Service] Environment=DOCKER_OPTS='--registry-mirror=http://$private_ipv4:5000' </del> - name: kube-apiserver.service command: start content: | [Unit] Description=Kubernetes API Server Documentation=https://github.com/GoogleCloudPlatform/kubernetes <del> Requires=etcd2.service After=etcd2.service </del> <ins> Requires=etcd2.service setup-network-environment.service After=etcd2.service setup-network-environment.service </ins> [Service] <ins> EnvironmentFile=/etc/network-environment </ins> ExecStartPre=-/usr/bin/mkdir -p /opt/bin ExecStartPre=/usr/bin/wget -N -P /opt/bin https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver

--secure_port=6443  --portal_net=10.100.0.0/16  --etcd_servers=http://127.0.0.1:4001  <del> --public_address_override=$private_ipv4  </del> <ins> --public_address_override=${DEFAULT_IPV4}  </ins> --logtostderr=true Restart=always RestartSec=10

[Service] # ExecStartPre=/usr/bin/wget -N -P /opt/bin https://storage.googleapis.com/k8s/kube-register <del> ExecStartPre=/usr/bin/wget -N -O /opt/bin/kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.3/kube-register-0.0.3-linux-amd64 </del> <ins> ExecStartPre=/usr/bin/curl -L -o /opt/bin/kube-register -z /opt/bin/kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.3/kube-register-0.0.3-linux-amd64 </ins> ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-register ExecStart=/opt/bin/kube-register  --metadata=role=node 

ExecStart=/opt/bin/kubelet  --address=0.0.0.0  --port=10250  <del> --hostname_override=$private_ipv4  </del> <ins> --hostname_override=${DEFAULT_IPV4}  </ins> --api_servers=<master-private-ip>:8080  --allow_privileged=true  --logtostderr=true
Change:
We should call kube-down in e2e when running teardown. Currently we just . In doing so we also need to ensure that minion-2 is torn down. When calling cluster/kube- manually master and minion-1 are torn down correctly while minion-2 is missed. /cc
I think sorting this out should resolve any issues from and

Discussion:
# Execute after running tests to perform any required clean-up function test-teardown { <del> echo "Vagrant ignores tear-down" 1>&2 </del> <ins> kube-down </ins> } # Set the {user} and {password} environment values required to interact with provider
Change:
I tried the json file in docs/downward API. After the pod is created, the environment variables are created but have empty value: The json file in the doc has a few grammar issues, so I modified it a bit:

Discussion:
This is an example of a pod that consumes its name and namespace via the downward API: <del> ```json { "apiVersion":"v1beta3", "name": "downward-api-pod", "kind": "Pod", "spec": { "manifest": { "containers": [{ "name": "example-container", "image": "gcr.io/google_containers/busybox", "command": [ "sh", "-c", "env" ] "env": [{ "name": "POD_NAMESPACE", "valueFrom": { "fieldPath": { "apiVersion": "v1beta3", "fieldPath": "metadata.namespace" } } }, { "name": "POD_NAME", "valueFrom": { "fieldPath": { "apiVersion": "v1beta3", "fieldPath": "metadata.name" } } }] }] } } }] </del> <ins> ```yaml apiVersion: v1beta3 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace restartPolicy: Never </ins> ```
Change:
In the step 1) of docs Clone repo kubernetes via ssh would fail: Better to change it to the .
hello, I am not the owner of k8s, but I can clone vis ssh. Maybe it's your github key issue.
In any case, the docs generally tell us to use https or so I've opened a PR to change it to https. Edit: Though I also have no issue with using ssh, it clones just fine.
Hmm so I've just tested this from a computer that has not previously interacted with github (a little debian server). It fails similarly when cloning over ssh, giving the same output as reported by We should still probably switch the docs to https.

Discussion:
### **Main Steps** #### I. Make *kubernetes* , *etcd* and *flanneld* binaries <del> First clone the kubernetes github repo, `$ git clone git@github.com:GoogleCloudPlatform/kubernetes.git` </del> <ins> First clone the kubernetes github repo, `$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git` </ins> then `$ cd kubernetes/cluster/ubuntu`. Then run `$ ./build.sh`, this will download all the needed binaries into `./binaries`.
Change:
is running in to an issue where the operation ID pulled from the MIG delete command during GCE kube-down is incorrect:
Looks like this is caused by OS X using non-GNU . A couple of different possible fixes, one is to force check for and use that when available. Another approach, courtesy of is to just limit our self to non-GNU .

Discussion:
"${NODE_INSTANCE_PREFIX}-group") if [[ "$deleteCmdOutput" != ""  ]]; then # Managed instance group deletion is done asyncronously, we must wait for it to complete, or subsequent steps fail <del> deleteCmdOperationId=$(echo $deleteCmdOutput | grep "Operation:" | sed "s/.*Operation:s//" | sed "s/s.*//" | sed "s/ //g") </del> <ins> deleteCmdOperationId=$(echo $deleteCmdOutput | grep "Operation:" | sed "s/.*Operation:[[:space:]]*([^[:space:]]*).*/1/g") </ins> if [[ "$deleteCmdOperationId" != ""  ]]; then deleteCmdStatus="PENDING" while [[ "$deleteCmdStatus" != "DONE" ]] do <del> sleep 5 </del> <ins> sleep 5 </ins> deleteCmdOperationOutput=$(gcloud preview managed-instance-groups --zone "${ZONE}" get-operation $deleteCmdOperationId) <del> deleteCmdStatus=$(echo $deleteCmdOperationOutput | grep -i "status:" | sed "s/.*status:s//" | sed "s/s.*//" | sed "s/ //g") </del> <ins> deleteCmdStatus=$(echo $deleteCmdOperationOutput | grep -i "status:" | sed "s/.*status:[[:space:]]*([^[:space:]]*).*/1/g") </ins> echo "Waiting for MIG deletion to complete. Current status: " $deleteCmdStatus done fi
Change:
Error on reading termination-log /var/lib/kubelet/pods/-f986-11e4-9c82-/containers/skydns/933ddf81dbaf586e425240432429aa57bec939383e19bfb25d35d478597203f7: open /var/lib/kubelet/pods/-f986-11e4-9c82-/containers/skydns/933ddf81dbaf586e425240432429aa57bec939383e19bfb25d35d478597203f7: no such file or directory
I think there is a regression lately breaking termination-log.
might be related to this issue.
Was this fixed by ?
No, I still observed such error logs once a while, but so far those errors are red herring, without any breakage. Haven't get down to look into the detail yet.
If a pod gets deleted from the apiserver, kubelet (more specifically, the SyncPods function) would stop the container, and remove the orphaned volumes and pod directories. In the meantime, the per-pod workers (goroutines) may not have terminated yet. Therefore, the workers could be inspecting the containers to generate the status, causing the errors. Note that this does not happen if containers terminated by themselves while the pod is not yet deleted. The error messages are harmless, since the pods have been deleted and no one would examine the termination logs anyway. However, the fact that is full of such errors is misleading and confusing to users. I think this would be solved by graceful termination...

Discussion:
if found { data, err := ioutil.ReadFile(path) if err != nil { <del> glog.Errorf("Error on reading termination-log %s: %v", path, err) </del> <ins> result.status.State.Terminated.Message = fmt.Sprintf("Error on reading termination-log %s: %v", path, err) </ins> } else { result.status.State.Terminated.Message = string(data) }
Change:
When debugging , I found the output of 'kubectl get pods' was misleading, The status of the pod was reported as , but a further suggested the pod was not ready: shall warn the user about the fact that the pod is not ready.

Discussion:
if state != nil { message = fmt.Sprintf("exit code %d", state.ExitCode) if state.Reason != "" { <del> message = fmt.Sprintf("%s, reason: %s", state.Reason) </del> <ins> message = fmt.Sprintf("%s, reason: %s", message, state.Reason) </ins> } } return message

if message != "" { message = "last termination: " + message } <del> return "Running", translateTimestamp(state.Running.StartedAt), message, nil </del> <ins> stateMsg := "Running" if !status.Ready { stateMsg = stateMsg + " *not ready*" } return stateMsg, translateTimestamp(state.Running.StartedAt), message, nil </ins> } else if state.Termination != nil { return "Terminated", translateTimestamp(state.Termination.StartedAt), getTermMsg(state.Termination), nil }

} } } <ins> func TestInterpretContainerStatus(t *testing.T) { tests := []struct { status          *api.ContainerStatus expectedState   string expectedMessage string expectErr       bool name            string }{ { status: &api.ContainerStatus{ State: api.ContainerState{ Running: &api.ContainerStateRunning{}, }, Ready: true, }, expectedState:   "Running", expectedMessage: "", name:            "basic", }, { status: &api.ContainerStatus{ State: api.ContainerState{ Running: &api.ContainerStateRunning{}, }, Ready: false, }, expectedState:   "Running *not ready*", expectedMessage: "", name:            "basic not ready", }, { status: &api.ContainerStatus{ State: api.ContainerState{ Waiting: &api.ContainerStateWaiting{}, }, Ready: false, }, expectedState:   "Waiting", expectedMessage: "", name:            "waiting not ready", }, { status: &api.ContainerStatus{ State: api.ContainerState{ Waiting: &api.ContainerStateWaiting{}, }, Ready: true, }, expectedState:   "Waiting", expectedMessage: "", name:            "waiting", }, { status: &api.ContainerStatus{ State: api.ContainerState{ Termination: &api.ContainerStateTerminated{ ExitCode: 3, }, }, Ready: false, }, expectedState:   "Terminated", expectedMessage: "exit code 3", name:            "terminated not ready", }, { status: &api.ContainerStatus{ State: api.ContainerState{ Termination: &api.ContainerStateTerminated{ ExitCode: 5, Reason:   "test reason", }, }, Ready: true, }, expectedState:   "Terminated", expectedMessage: "exit code 5, reason: test reason", name:            "terminated", }, } for _, test := range tests { // TODO: test timestamp printing. state, _, msg, err := interpretContainerStatus(test.status) if test.expectErr && err == nil { t.Errorf("unexpected non-error (%s)", test.name) continue } if !test.expectErr && err != nil { t.Errorf("unexpected error: %v (%s)", err, test.name) continue } if state != test.expectedState { t.Errorf("expected: %s, got: %s", test.expectedState, state) } if msg != test.expectedMessage { t.Errorf("expected: %s, got: %s", test.expectedMessage, msg) } } } </ins>
Change:
has a dependency on pkg/api for , which it embeds in . Is it doing that to take advantage of validation code, or can Config just declare and directly and avoid the dependency?
A quick try (just declaring a in the package) seems to work fine with . I only included those out of habit.
Out of curiosity, is this just for a proper separate of packages or is there some functional issue as well?
mentioned encountering an issue with tests, but it's mostly just for proper separation of packages.
Related: Remove json tags from
See also
Not done:

Discussion:
package api import ( <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" )

// Config holds the information needed to build connect to remote kubernetes clusters as a given user type Config struct { <del> api.TypeMeta `json:",inline"` </del> <ins> // Legacy field from pkg/api/types.go TypeMeta. // TODO(jlowdermilk): remove this after eliminating downstream dependencies. Kind string `json:"kind,omitempty"` // Version of the schema for this config object. APIVersion string `json:"apiVersion,omitempty"` </ins> // Preferences holds general information to be use for cli interactions Preferences Preferences `json:"preferences"` // Clusters is a map of referencable names to cluster configs
Change:
has a dependency on pkg/api for , which it embeds in . Is it doing that to take advantage of validation code, or can Config just declare and directly and avoid the dependency?
A quick try (just declaring a in the package) seems to work fine with . I only included those out of habit.
Out of curiosity, is this just for a proper separate of packages or is there some functional issue as well?
mentioned encountering an issue with tests, but it's mostly just for proper separation of packages.
Related: Remove json tags from
See also
Not done:

Discussion:
package v1 import ( <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/v1beta3" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" )

// Config holds the information needed to build connect to remote kubernetes clusters as a given user type Config struct { <del> v1beta3.TypeMeta `json:",inline"` </del> <ins> // Legacy field from pkg/api/types.go TypeMeta. // TODO(jlowdermilk): remove this after eliminating downstream dependencies. Kind string `json:"kind,omitempty"` // Version of the schema for this config object. APIVersion string `json:"apiVersion,omitempty"` </ins> // Preferences holds general information to be use for cli interactions Preferences Preferences `json:"preferences"` // Clusters is a map of referencable names to cluster configs
Change:
Though I have successfully installed kubernetes via :smiley: , still want to point out this doc missing the step to install . Thus, if user just follow the guide in the doc without having much knowledge about kubernetes, he/she would get error "It looks as if you don't have a compiled kubectl binary" during the step of . Manually install kubectl on at least master node should be necessary (suggest to let user also install on minion node for convenience), any way, the installation step is .
I forget to mention that.I will update the doc this tuned
I update the scripts in pr , you can try it now. I copied the kubectl binary from the kubernetes release and put it in , so there is no extra step for user to manually download . Actually, in the first version of ubuntu k8s deployment, I copied the to every node, but I think it is an overhead, so I removed it.I think this is just enough.
Doc update : Move the kubectl into the PATH, it may need sudo privilege so I decide not do for the user.
Have the same issue, please update the doc ASAP.
Great job :+1:
Also ran into this bug after recklessly running ( instead of ) :)

Discussion:
cp kubernetes/server/kubernetes/server/bin/kubelet  kubernetes/server/kubernetes/server/bin/kube-proxy binaries/minion <ins> cp kubernetes/server/kubernetes/server/bin/kubectl binaries/ </ins> rm -rf flannel* kubernetes* etcd* echo "Done! All your commands locate in ./binaries dir"

MASTER_IP="" MINION_IPS="" <ins> KUBECTL_PATH=${KUBE_ROOT}/cluster/ubuntu/binaries/kubectl </ins> # Assumed Vars: #   KUBE_ROOT function test-build-release {

**All done !** <del> You can also use kubectl command to see if the newly created k8s is working correctly. </del> <ins> You can also use `kubectl` command to see if the newly created k8s is working correctly. The `kubectl` binary is under the `cluster/ubuntu/binaries` directory. You can move it into your PATH. Then you can use the below command smoothly. </ins> For example, use `$ kubectl get minions` to see if you get all your minion nodes comming up and ready. It may take some times for the minions be ready to use like below.