jiebi/CodeConvo huggingface dataset:
Change:
During our Jenkins run, a cluster failed to initialize with a pattern like so: I logged into the second node to see what was going on, and found the kubelet logs seemed to be repeating themselves every couple of minutes: Checking monit, yup: Jenkins is currently disabled to allow live debugging of the issue. Raising to P0 until we get Jenkins back. cc
I can login to the node and working on it now.
Here is what happened: Docker daemon is hung during startup phase: But nono docker CLI calls return, including 'docker version'. Monit now does healthcheck on kubelet, which in turns to query docker version, which never response and timeout, and cause a kubelet restart. Looking into why docker daemon hang forever.
Ok, that docker daemon on a terrible state, and all docker API requests hang. This is known issue from docker since I personally reported twice. The current active one is docker/docker/issues/9605. 1) I tried to strace docker process for about 20 seconds, and nothing is interesting except one thread stucking at read syscall forever: 2) I sent SIGQUIT to docker daemon. Docker is shutdown, and restart by monit. From below log, one can notice that there is a huge gap between time="2015-03-11T17:58:25Z" and time="2015-03-11T21:06:06Z" 3) Monit now restart docker daemon: Assuming there are always docker API request hang issues, we should detect such issue, and restart docker like what I did for kubelet. Meanwhile, we shouldn't fail kubelet's healthcheck when docker API hang.
This is part of
Thanks for the quick fix!

Discussion:
start program = "/etc/init.d/docker start" stop program = "/etc/init.d/docker stop" if does not exist then restart <ins> if failed unixsocket /var/run/docker.sock protocol HTTP request "/version" then restart </ins>
Change:
When spinning up VMs w/ kube, I attempted to use but this fails. ironically, 127.0.0.1 succeeds (internally you can then access a kube service via , for example, but you cannot do this if you try to bind to 0.0.0.0. binding works to 127.0.0.1, but is a horrible idea (since this IP wont be reachable by the outside world), so in that case kube should print a clear message on why this is the case and fail. binding to 0.0.0.0 fails right out of the bat, so in this case, also, kube should fail immediately. To be clear, im suggesting that these should fail at the service submission layer. Possibly a module for validating logic of submitted services/pods , which extends syntactical validation is in order if one doesn't already exist?
Please also see
Since this is very similar to I'm gonna take this.

Discussion:
} } <ins> for _, ip := range service.Spec.PublicIPs { if ip == "0.0.0.0" { allErrs = append(allErrs, errs.NewFieldInvalid("spec.publicIPs", ip, "is not an IP address")) } else if util.IsValidIP(ip) && net.ParseIP(ip).IsLoopback() { allErrs = append(allErrs, errs.NewFieldInvalid("spec.publicIPs", ip, "publicIP cannot be a loopback")) } } </ins> return allErrs }

numErrs: 1, }, { <ins> name: "invalid publicIPs localhost", makeSvc: func(s *api.Service) { s.Spec.PublicIPs = []string{"127.0.0.1"} }, numErrs: 1, }, { name: "invalid publicIPs", makeSvc: func(s *api.Service) { s.Spec.PublicIPs = []string{"0.0.0.0"} }, numErrs: 1, }, { name: "valid publicIPs host", makeSvc: func(s *api.Service) { s.Spec.PublicIPs = []string{"myhost.mydomain"} }, numErrs: 0, }, { </ins> name: "nil selector", makeSvc: func(s *api.Service) { s.Spec.Selector = nil

package util import ( <ins> "net" </ins> "regexp" )

func IsValidPortNum(port int) bool { return 0 < port && port < 65536 } <ins> // IsValidIP tests that the argument is a valid IPv4 address. func IsValidIP(value string) bool { return net.ParseIP(value) != nil && net.ParseIP(value).To4() != nil } </ins>

} } } <ins> func TestIsValidIP(t *testing.T) { goodValues := []string{ "1.1.1.1", "1.1.1.01", "255.0.0.1", "1.0.0.0", "0.0.0.0", } for _, val := range goodValues { if !IsValidIP(val) { t.Errorf("expected true for %q", val) } } badValues := []string{ "2a00:79e0:2:0:f1c3:e797:93c1:df80", // This is valid IPv6 "a", "myhost.mydomain", "-1.0.0.0", "1.0.0.256", "1.0.0.1.1", "1.0.0.1.", } for _, val := range badValues { if IsValidIP(val) { t.Errorf("expected false for %q", val) } } } </ins>
Change:
I was tring to build kubernetes following But failed for some times. I looked into the error and found it's because I'm behind a proxy. Then I edited the dockerfile under build/build-image/ folder, some proxy settings into it and solved the problem. Though it may not be a problem for experienced guys. Would it be better for the beginners to describe these detaied settings in the document? Can I add the proxy settings I found into the doc? I'm new to kubernetes and need your opinion.
Yes, please, by all means. Please describe your problem and the solution in the doc and send a PR.

Discussion:
When building final release tars, they are first staged into `_output/release-stage` before being tar'd up and put into `_output/release-tars`. <ins> ## Proxy Settings If you are behind a proxy, you need to edit `build/build-image/Dockerfile` and add proxy settings to execute command in that container correctly. example: `ENV http_proxy http://username:password@proxyaddr:proxyport` `ENV https_proxy http://username:password@proxyaddr:proxyport` Besides, to avoid integration test touch the proxy while connecting to local etcd service, you need to set `ENV no_proxy 127.0.0.1` </ins> ## TODOs These are in no particular order
Change:
On GCE, when I run to push new binaries to e2e cluster, the binaries are not pushed.
I lost a lot of time due to this bug today. I was debugging failing e2e tests, and I was using this command often. I took me some time before I realized it doesn't work and I need to do each time.
Can you be specific? I verified apiserver push at least, and I manually inspected kubelet, but it's fidgety to test push. On Mar 12, 2015 8:16 AM, "Satnam Singh" wrote:
The scenario: compiled the old version and installed it with -v -build -up; run some e2e tests, cluster with the old version was running; changed source code of some files in pkg/apiserver or pkg/registry/pod; compiled the new version and was trying to install it with -v -build -push; run some e2e tests, hoping the new version of apiserver was deployed. However, the old version was still running during step 5. It seemed that step 4. compiled the new version, but didn't deploy it. To deploy the new version I needed to run -up.
I did tests to verify that I was no longer seeing version mismatches after a push (which is a good sign that a push succeeded in bonking the apiserver), but I'll see if I can do more rigorous testing soon. To be honest, the master push hasn't changed much - the node deployment was the part that changed much more radically with the Salt changes. So I'm not exactly sure what you're seeing here. , Jerzy Szczepkowski < :

Discussion:
ensure-install-dir set-kube-env create-salt-pillar <ins> download-release </ins> run-salt echo "== kube-push node config done ==" fi
Change:
Observed in testing somehting unrelated - prio We need a test that captures this - we can't let this slip through, Maybe same as ?
I just reproduced this with newly built cluster from HEAD. This is definitely a regression introduced lately. Will look into it in detail.

Discussion:
// FindContainersByPod returns the containers that belong to the pod. func (c DockerContainers) FindContainersByPod(podUID types.UID, podFullName string) DockerContainers { containers := make(DockerContainers) for _, dockerContainer := range c { if len(dockerContainer.Names) == 0 { continue

fakeDocker.ContainerList = []docker.APIContainers{ { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> <del> Names: []string{"/k8s_bar_foo_new_12345678_0"}, </del> <ins> Names: []string{"/k8s_bar1_foo1_new_12345678_0"}, </ins> ID:    "1234", }, <ins> { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_bar2_foo2_new_87654321_0"}, ID:    "5678", }, { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_POD_foo2_new_87654321_0"}, ID:    "8765", }, </ins> } kubelet.pods = []api.BoundPod{ { ObjectMeta: api.ObjectMeta{ UID:       "12345678", <del> Name:      "foo", </del> <ins> Name:      "foo1", </ins> Namespace: "new", }, Spec: api.PodSpec{ Containers: []api.Container{ <del> {Name: "bar"}, </del> <ins> {Name: "bar1"}, }, }, }, { ObjectMeta: api.ObjectMeta{ UID:       "87654321", Name:      "foo2", Namespace: "new", }, Spec: api.PodSpec{ Containers: []api.Container{ {Name: "bar2"}, </ins> }, }, }, } <del> waitGroup.Add(1) </del> <ins> waitGroup.Add(2) </ins> err := kubelet.SyncPods(kubelet.pods, emptyPodUIDs, time.Now()) if err != nil { t.Errorf("unexpected error: %v", err)

waitGroup.Wait() verifyCalls(t, fakeDocker, []string{ <del> "list", "list", "stop", "create", "start", "inspect_container", "create", "start"}) </del> <ins> "list", "list", "list", "list", "inspect_container", "inspect_container", "stop", "create", "start", "inspect_container", "create", "start"}) </ins> // A map iteration is used to delete containers, so must not depend on // order here.
Change:
I made several attempts to update the apiserver (i.e. on the master) using and but they failed to update the binary. I noticed the same PID on the master for and a long uptime. If I tore the cluster down and rebuilt it then I could see the change I made to the apiserver.
I'm actively working on it.
I noticed exact the same issue today by update my kubelet binary.
Push is broken, sorry. I thought I tested it, but the binaries aren't getting bonked appropriately.
kubelet binary push actually worked before? That path looked dubious at best. On Mar 12, 2015 3:56 PM, "Dawn Chen" wrote:
I would appreciate external testing. I have done some sniff testing, but push is a really broad use-case. , Satnam Singh wrote:
reopen this since the fix is reversed.

Discussion:
ensure-install-dir set-kube-env create-salt-pillar <ins> download-release </ins> run-salt echo "== kube-push node config done ==" fi
Change:
Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)

Discussion:
import ( "fmt" "reflect" <ins> "sort" </ins> "sync" "time"

return } <ins> func (f *FakeDockerClient) AssertUnorderedCalls(calls []string) (err error) { f.Lock() defer f.Unlock() var actual, expected []string copy(actual, calls) copy(expected, f.called) sort.StringSlice(actual).Sort() sort.StringSlice(expected).Sort() if !reflect.DeepEqual(actual, expected) { err = fmt.Errorf("expected(sorted) %#v, got(sorted) %#v", expected, actual) } return } </ins> // ListContainers is a test-spy implementation of DockerInterface.ListContainers. // It adds an entry "list" to the internal method call record. func (f *FakeDockerClient) ListContainers(options docker.ListContainersOptions) ([]docker.APIContainers, error) {

"path" "reflect" "regexp" <ins> "sort" </ins> "strconv" "strings" "sync"

} } <ins> func verifyUnorderedCalls(t *testing.T, fakeDocker *dockertools.FakeDockerClient, calls []string) { err := fakeDocker.AssertUnorderedCalls(calls) if err != nil { t.Error(err) } } </ins> func verifyStringArrayEquals(t *testing.T, actual, expected []string) { invalid := len(actual) != len(expected) if !invalid {

} func verifyStringArrayEqualsAnyOrder(t *testing.T, actual, expected []string) { <del> invalid := len(actual) != len(expected) if !invalid { for _, exp := range expected { found := false for _, act := range actual { if exp == act { found = true break } } if !found { t.Errorf("Expected element %q not found in %#v", exp, actual) } } } if invalid { t.Errorf("Expected: %#v, Actual: %#v", expected, actual) </del> <ins> var act, exp []string copy(act, actual) copy(exp, expected) sort.StringSlice(act).Sort() sort.StringSlice(exp).Sort() if !reflect.DeepEqual(exp, act) { t.Errorf("Expected(sorted): %#v, Actual(sorted): %#v", exp, act) </ins> } }

} waitGroup.Wait() <del> verifyCalls(t, fakeDocker, []string{ </del> <ins> verifyUnorderedCalls(t, fakeDocker, []string{ </ins> "list", "list", "list", "list", "inspect_container", "inspect_container", "list", "inspect_container", "inspect_container", "stop", "create", "start", "inspect_container", "create", "start", "list", "inspect_container", "inspect_container"}) // A map iteration is used to delete containers, so must not depend on
Change:
committed a changed version of go into godeps. Was this deliberate? I don't see any discussion of it ( I've almost done this by mistake as well, so I'm inclined to think it was just an oversight. (I think this is giving me errors building, but I'm not yet 100% sure this is the cause)
Hmm, this is a good point. It does look to be accidental. I don't know. I think and would have context though I believe they are out— do you know offhand whether this is probably an accident? I guess were talking specifically about in the .
I believe it's an accident.
Thanks, The linked PR should fix this (assuming I don't have to do anything else with Godeps).
This was almost certainly an accident. Whenever I've updated godeps it's changed automatically to 1.3 and I've had to adjust it back manually.
Actually, jeff lowdermilk was super helpful and showed me how to update the deps on this PR. it was his commit which I merged into my PR, so not sure it it was accidental or not. Fortunately, now that k8petstore is in the go build, we will know if it breaks anything when you revert the version back. Thanks for noticing this. , Alex Robinson wrote:

Discussion:
{ "ImportPath": "github.com/GoogleCloudPlatform/kubernetes", <del> "GoVersion": "go1.3", </del> <ins> "GoVersion": "go1.4.1", </ins> "Packages": [ "./..." ],
Change:
Working through the , I was confused about how to get setup with an initial binary and cluster. I think the section should point to the , rather than the document. relies on , which is being deprecated, and just points to the getting-started guides anyway.
LGTM.

Discussion:
### Step Zero: Prerequisites <del> This example assumes that you have a basic understanding of kubernetes services and that you have forked the repository and [turned up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#contents): This example requires a kubernetes cluster. </del> <ins> This example requires a kubernetes cluster.  See the [Getting Started guides](../../docs/getting-started-guides) for how to get started. </ins> <del> See the companion [Setup Kubernetes](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/guestbook/SETUP.md) for some quick notes on how to get started. *If* you are running from source, replace commands such as "kubectl" below with calls to cluster/kubectl.sh. </del> <ins> If you are running from source, replace commands such as `kubectl` below with calls to `cluster/kubectl.sh`. </ins> ### Step One: Fire up the redis master

<del> ## Getting Started This example requires that you have forked the repository and [fired up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#contents. On some setups, this can be as easy as running: ```shell $ cd kubernetes $ hack/dev-build-and-up.sh ``` For others, there are also many other ways to set up a kubernetes cluster.  For comprehensive directions on setting up, see the getting started guides [Getting Started Guides](https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs/getting-started-guides). </del>
Change:
On a cluster running 0.13.2, I ran , picked out the name of a pod that only contains a single container, let's call it foo, and then ran . It prints nothing other than the message "Unexpected path for command running". If I add on the container name (), then it prints nothing, presumably because the pod has no logs. The docs for kubectl log say that the container name is optional if the pod only has one container, so I wouldn't expect this response.
+1, we're having to work around this on guides

Discussion:
var container string if len(args) == 1 { <ins> if len(pod.Spec.Containers) != 1 { return fmt.Errorf("POD %s has more than one container; please specify the container to print logs for", pod.ObjectMeta.Name) } container = pod.Spec.Containers[0].Name </ins> } else { container = args[1] }

if client.IsUnexpectedStatusError(err) { glog.FatalDepth(1, fmt.Sprintf("Unexpected status received from server: %s", err.Error())) } <del> glog.FatalDepth(1, fmt.Sprintf("Error: %s", err.Error())) </del> <ins> glog.FatalDepth(1, fmt.Sprintf("Client error: %s", err.Error())) </ins> } }
Change:
The bug is around line 261 in "" It seems that the test is expecting a file just written to have appeared immediately, and that doesn't seem to actually occur. Here's the chunk of code I'm talking about: When run on some systems (it seems to depend on something like filesystem, exact arch, whether you're in boot2docker, etc.) this eventually outputs the following error: F0324 19:38:20. 696 ] static-pod-from-manifest FAILED: mirror pod has not been created or is not running: Pod status is "Unknown" !!! Error in hack/test- '"1"' exited with status 255 Call stack: When I add "time.Sleep(30 * time.Second)" it works, on at least one system that it did not work on previously. If a sleep fixes it, it must be a race. I'm not sure of the best solution, the sleep works, but is of course absolutely horrid. thanks!
Hi thanks for reporting the bug! The test was supposed to poll every second until the 2 minutes timeout, so the extra sleep should not be needed. There was a bug causing problems, and it was fixed by yesterday. Are you running HEAD? If not, could you try running again with HEAD? Thanks!
Actually I think there is a bug in podRunning method. It never waits for PodRunning phase - it returns error on the first check. I'll send PR to fix this.
Indeed... my hostname is "slate", all lower-case, and this is on linux. I should've mentioned that. But, it looks like you already caught the real race. Thanks for the fix!

Discussion:
return false, nil } if err != nil { <del> return false, err </del> <ins> // This could be a connection error so we want to retry, but log the error. glog.Errorf("Error when reading pod %q: %v", podID, err) return false, nil </ins> } if pod.Status.Phase != api.PodRunning { <del> return false, errors.New(fmt.Sprintf("Pod status is %q", pod.Status.Phase)) </del> <ins> return false, nil </ins> } return true, nil }
Change:
While running one of my soak tests I noticed the error message: I don't see why I should get this error message. Why should it matter if the namespace already exists? It was created as part of the service creation call just beforehand. And the second attempt to create this pod in exactly the same namespace works. Is this a bug?
Running a second time did not produce this error.
I agree it should not matter. The error is produced there, and I suspect there were multiple concurrent calls being made that try to create a resource in a namespace that had not yet existed. We need to update the code in question to swallow the error if the namespace already exists.
FYI - longer term, I would like to eliminate the use of autoprovision of namespace and require you to first create a namespace manually. what is there now is more to preserve existing behavior prior to namespace as object was introduced.

Discussion:
func (c *FakeNamespaces) Create(namespace *api.Namespace) (*api.Namespace, error) { c.Fake.Actions = append(c.Fake.Actions, FakeAction{Action: "create-namespace"}) <del> return &api.Namespace{}, nil </del> <ins> return &api.Namespace{}, c.Fake.Err </ins> } func (c *FakeNamespaces) Update(namespace *api.Namespace) (*api.Namespace, error) {

"github.com/GoogleCloudPlatform/kubernetes/pkg/admission" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/meta" "github.com/GoogleCloudPlatform/kubernetes/pkg/client"

return nil } _, err = p.client.Namespaces().Create(namespace) <del> if err != nil { </del> <ins> if err != nil && !errors.IsAlreadyExists(err) { </ins> return err } return nil

"github.com/GoogleCloudPlatform/kubernetes/pkg/admission" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/client/cache" )

t.Errorf("No client request should have been made") } } <ins> // TestAdmissionNamespaceExistsUnknownToHandler func TestAdmissionNamespaceExistsUnknownToHandler(t *testing.T) { namespace := "test" mockClient := &client.Fake{ Err: errors.NewAlreadyExists("namespaces", namespace), } store := cache.NewStore(cache.MetaNamespaceKeyFunc) handler := &provision{ client: mockClient, store:  store, } pod := api.Pod{ ObjectMeta: api.ObjectMeta{Name: "123", Namespace: namespace}, Spec: api.PodSpec{ Volumes:    []api.Volume{{Name: "vol"}}, Containers: []api.Container{{Name: "ctr", Image: "image"}}, }, } err := handler.Admit(admission.NewAttributesRecord(&pod, namespace, "pods", "CREATE")) if err != nil { t.Errorf("Unexpected error returned from admission handler") } } </ins>
Change:
Integration tests run the same test for v1beta1 and v1beta3. Sometimes second run fails complaining: This causes some flakes in travis/shippable. We should wait for the clean shutdown of the first run and only then start the second one.

Discussion:
kube::etcd::cleanup() { kill "${ETCD_PID-}" >/dev/null 2>&1 || : <ins> wait "${ETCD_PID-}" >/dev/null 2>&1 || : </ins> rm -rf "${ETCD_DIR-}" }