jiebi/CodeConvo huggingface dataset:
Change:
In , there is a local constant named containerPollTime that is put to two very different uses --- waiting for a pod to come up, and recovering from pods getting "lost". The former needs to be very responsive, but the latter does not (but is still costly when the number of pods grows). The value is currently set to one second, and that makes both things happen frequently. It would be better if there were two different constants, so the monitoring for lost pods can be less frequent.

Discussion:
const ( containerPollTime = 1 * time.Second <ins> lostPodPollTime   = 1 * time.Minute </ins> podRelistPeriod   = 5 * time.Minute )

// Wait for the pod to go away and stop monitoring once it does // TODO (jdefelice) replace with an /events watch? for { <del> time.Sleep(containerPollTime) </del> <ins> time.Sleep(lostPodPollTime) </ins> if k.checkForLostPodTask(driver, taskId, knownPod) { return }
Change:
It failed on cc - please fix or reassign.
ping I am tempted to just disable the test per our standard protocol for dealing with Mesos test problems that aren't fixed in a timely fashion, but since it's a flake I'm willing to wait until it flakes again (unless you fix it first).
FYI - I've opened a PR w/ a fix , David Oppenheimer

Discussion:
<-called close(ch) <del> <-called </del> <ins> // wait for 'called' to be closed for { if _, ok := <-called; !ok { break } } </ins> //-- ch = make(chan struct{}) <del> called = make(chan struct{}) </del> <ins> called2 := make(chan struct{}) </ins> running := make(chan struct{}) After(func() { Until(func() { close(running) <del> called <- struct{}{} </del> <ins> called2 <- struct{}{} </ins> }, 2*time.Second, ch) <del> }).Then(func() { close(called) }) </del> <ins> }).Then(func() { close(called2) }) </ins> <-running close(ch) <del> <-called // unblock the goroutine </del> <ins> <-called2 // unblock the goroutine </ins> now := time.Now() <del> <-called </del> <ins> // wait for 'called2' to be closed for { if _, ok := <-called2; !ok { break } } </ins> if time.Since(now) > 1800*time.Millisecond { t.Fatalf("Until should not have waited the full timeout period since we closed the stop chan") }
Change:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.

Discussion:
-v "${REPO_DIR}":/go/src/k8s.io/kubernetes  -v "${KUBE_JUNIT_REPORT_DIR}":/workspace/artifacts  --env REPO_DIR="${REPO_DIR}"  <del> -i gcr.io/google_containers/kubekins-test:0.5  </del> <ins> -i gcr.io/google_containers/kubekins-test:0.6  </ins> bash -c "cd kubernetes && ./hack/jenkins/test-dockerized.sh"

WORKDIR /workspace RUN apt-get -o Acquire::Check-Valid-Until=false update && apt-get install -y rsync <ins> # file is used when uploading test artifacts to GCS. RUN apt-get install -y file </ins> # libapparmor1 is needed for docker-in-docker. <del> RUN apt-get install -y file libapparmor1 </del> <ins> RUN apt-get install -y libapparmor1 # netcat is used by integration test scripts. RUN apt-get install -y netcat-openbsd </ins> RUN mkdir -p /go/src/k8s.io/kubernetes RUN ln -s /go/src/k8s.io/kubernetes /workspace/kubernetes

all: push <del> TAG = 0.5 </del> <ins> TAG = 0.6 </ins> container: docker build -t gcr.io/google_containers/kubekins-test .

# returns a random port kube::util::get_random_port() { <del> awk -v min=1 -v max=65535 'BEGIN{srand(); print int(min+rand()*(max-min+1))}' </del> <ins> awk -v min=1024 -v max=65535 'BEGIN{srand(); print int(min+rand()*(max-min+1))}' </ins> } # use netcat to check if the host($1):port($2) is free (return 0 means free, 1 means used)

return ${success} } <del> if [ ! $(nc -vz "${host} ${port}") ]; then </del> <ins> if [ ! $(nc -vz "${host}" "${port}") ]; then </ins> kube::log::status "${host}:${port} is free, proceeding..." return ${success} else
Change:
Not sure if this is causing a problem, but it looks like the version test for salt can't find salt: cc in case you're still having trouble with AWS e2e

Discussion:
# Super annoying, the salt version on GCE is old enough that 'salt.cmd.run' # isn't supported {% if grains.cloud is defined and grains.cloud == 'aws' %} <del> {% set is_helium = salt.cmd.run('salt --version | grep -c Helium') %} </del> <ins> # Salt has terrible problems with systemd on AWS too {% set is_helium = '0' %} </ins> {% endif %} # Salt Helium doesn't support systemd modules for service running {% if pillar.get('is_systemd') and is_helium == '0' %}
Change:
On AWS, the kube-node-unpacker service is not starting, and so the kube-proxy is not starting, because the image is not registered. starts it. This is in : I suspect we're relying on salt to start a systemd service instead of using the workaround ;-) cc because will likely case AWS e2e to fail right now
I suspect this is actually the same as ; I suspect that the test for salt helium is failing and we are falling back to init.d
Obsoleted by

Discussion:
# Super annoying, the salt version on GCE is old enough that 'salt.cmd.run' # isn't supported {% if grains.cloud is defined and grains.cloud == 'aws' %} <del> {% set is_helium = salt.cmd.run('salt --version | grep -c Helium') %} </del> <ins> # Salt has terrible problems with systemd on AWS too {% set is_helium = '0' %} </ins> {% endif %} # Salt Helium doesn't support systemd modules for service running {% if pillar.get('is_systemd') and is_helium == '0' %}
Change:
This is not a problem when running kube-up because the kube-up for Ubuntu ensures that environment variable is defined. But when an operator runs , kubectl is invoked without ensuring KUBECONFIGFILE is defined and invokes detect-master without ensuring KUBECONFIGFILE is defined.

Discussion:
source "config-default.sh" KUBECTL="${KUBE_ROOT}/cluster/kubectl.sh" export KUBECTL_PATH="${KUBE_ROOT}/cluster/ubuntu/binaries/kubectl" <ins> export KUBE_CONFIG_FILE=${KUBE_CONFIG_FILE:-${KUBE_ROOT}/cluster/ubuntu/config-default.sh} </ins> function init { echo "Creating kube-system namespace..."
Change:
and provide for configuring Flannel's parameter but none of the others listed in

Discussion:
# define the IP range used for flannel overlay network, should not conflict with above SERVICE_CLUSTER_IP_RANGE export FLANNEL_NET=${FLANNEL_NET:-172.16.0.0/16} <ins> # Optionally add other contents to the Flannel configuration JSON # object normally stored in etcd as /coreos.com/network/config.  Use # JSON syntax suitable for insertion into a JSON object constructor # after other field name:value pairs.  For example: # FLANNEL_OTHER_NET_CONFIG=', "SubnetMin": "172.16.10.0", "SubnetMax": "172.16.90.0"' export FLANNEL_OTHER_NET_CONFIG FLANNEL_OTHER_NET_CONFIG='' </ins> # Admission Controllers to invoke prior to persisting objects in cluster export ADMISSION_CONTROL=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,SecurityContextDeny

exit 2 fi <del> /opt/bin/etcdctl mk /coreos.com/network/config "{"Network":"${FLANNEL_NET}", "Backend": {"Type": "vxlan"}}" </del> <ins> /opt/bin/etcdctl mk /coreos.com/network/config "{"Network":"${FLANNEL_NET}", "Backend": {"Type": "vxlan"}${FLANNEL_OTHER_NET_CONFIG}}" </ins> attempt=$((attempt+1)) sleep 3 fi

create-kube-controller-manager-opts '${NODE_IPS}' create-kube-scheduler-opts create-flanneld-opts '127.0.0.1' '${MASTER_IP}' <del> sudo -E -p '[sudo] password to start master: ' -- /bin/bash -ce ' </del> <ins> FLANNEL_OTHER_NET_CONFIG='${FLANNEL_OTHER_NET_CONFIG}' sudo -E -p '[sudo] password to start master: ' -- /bin/bash -ce ' </ins> ${BASH_DEBUG_FLAGS} cp ~/kube/default/* /etc/default/

'${MASTER_IP}' create-flanneld-opts '127.0.0.1' '${MASTER_IP}' <del> sudo -E -p '[sudo] password to start master: ' -- /bin/bash -ce ' </del> <ins> FLANNEL_OTHER_NET_CONFIG='${FLANNEL_OTHER_NET_CONFIG}' sudo -E -p '[sudo] password to start master: ' -- /bin/bash -ce ' </ins> ${BASH_DEBUG_FLAGS} cp ~/kube/default/* /etc/default/ cp ~/kube/init_conf/* /etc/init/

The `FLANNEL_NET` variable defines the IP range used for flannel overlay network, should not conflict with above `SERVICE_CLUSTER_IP_RANGE`. <ins> You can optionally provide additional Flannel network configuration through `FLANNEL_OTHER_NET_CONFIG`, as explained in `cluster/ubuntu/config-default.sh`. </ins> **Note:** When deploying, master needs to be connected to the Internet to download the necessary files. If your machines are located in a private network that need proxy setting to connect the Internet,
Change:
It fails all the time in . cc
I suspect the node was in a bad state. After deploying the new build, the test hasn't failed at all this week. Closing this and will re-open if it hits again.
It's failing again: and so on.
cc
The 0 pods per node test is more sensitive to noise caused by uneven distribution of cluster add-on pods. I adjusted the limits in to reflect the current kubelet status and also to account for the noise. Ideally we should disable the cluster add-ons in the cluster, but there is no easy way to do this in the current test framework. I think we should consider moving this test with hard limits to the node conformance test suite (where the addons are not enabled). We can keep this test here for monitoring purpose, but don't fail the build explicitly. We can integrate with other monitoring service and send alerts if necessary.
- actually it is easy to do during cluster startup. We can create a dedicated Node suite and run Node tests there (if it's not done already).
we actually just started node conformance tests in , which one of the v1.2 targets. It seems like this test might be a good fit there. cc will know more about porting/migrating tests to the node conformance suites.
Yes, one of the reasons we create a separate node test suite is moving this kind of test over. Let's try to move all node level resource tracking tests over to node test suite.
failing in https://k8s- https://k8s-
[FLAKE-PING] This flaky-test issue would love to have more attention.
This issue is not intended for GCI nor upgrade suites. Filing a new issue might be better. GCI has had problems with the docker memory usage for a while, as you can see in https://k8s- I think they fixed it in the latest dev image, but I am not sure if that was used in the upgrade tests.

Discussion:
rm.Stop() }) Describe("regular resource usage tracking", func() { <ins> // We assume that the scheduler will make reasonable scheduling choices // and assign ~N pods on the node. // Although we want to track N pods per node, there are N + add-on pods // in the cluster. The cluster add-on pods can be distributed unevenly // among the nodes because they are created during the cluster // initialization. This *noise* is obvious when N is small. We // deliberately set higher resource usage limits to account for the // noise. </ins> rTests := []resourceTest{ {podsPerNode: 0, limits: containersCPUSummary{ <del> "/kubelet":       {0.50: 0.05, 0.95: 0.15}, "/docker-daemon": {0.50: 0.03, 0.95: 0.06}, </del> <ins> "/kubelet":       {0.50: 0.06, 0.95: 0.08}, "/docker-daemon": {0.50: 0.05, 0.95: 0.06}, </ins> }, }, {podsPerNode: 35, limits: containersCPUSummary{ <del> "/kubelet":       {0.50: 0.15, 0.95: 0.35}, "/docker-daemon": {0.50: 0.06, 0.95: 0.30}, </del> <ins> "/kubelet":       {0.50: 0.12, 0.95: 0.14}, "/docker-daemon": {0.50: 0.06, 0.95: 0.08}, </ins> }, }, }
Change:
GCE updated docker, but only via a base-image update. AWS should match versions of docker, to slipstream off all the testing that GCE gets. This will be slightly complicated because docker 1.8.3 isn't in the bucket AFAICT. Thanks to for the tip.
This is done by

Discussion:
{% set storage_base='https://storage.googleapis.com/kubernetes-release/docker/' %} <ins> {% set override_deb_url='' %} </ins> {% if grains.get('cloud', '') == 'gce' and grains.get('os_family', '') == 'Debian' and grains.get('oscodename', '') == 'wheezy' -%}

{% set override_deb='' %} {% set override_deb_sha1='' %} {% set override_docker_ver='' %} <ins> # Ubuntu presents as os_family=Debian, osfullname=Ubuntu {% elif grains.get('cloud', '') == 'aws' and grains.get('os_family', '') == 'Debian' and grains.get('oscodename', '') == 'vivid' -%} # TODO: Get from google storage? {% set docker_pkg_name='docker-engine-1.8.3' %} {% set override_docker_ver='1.8.3' %} {% set override_deb='docker-engine_1.8.3-0~vivid_amd64.deb' %} {% set override_deb_url='http://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.8.3-0~vivid_amd64.deb' %} {% set override_deb_sha1='f0259b1f04635977325c0cfa7c0006e1e5de1341' %} </ins> {% else %} {% set docker_pkg_name='lxc-docker-1.7.1' %} {% set override_docker_ver='1.7.1' %}

{% set override_deb_sha1='81abef31dd2c616883a61f85bfb294d743b1c889' %} {% endif %} <ins> {% if override_deb_url == '' %} {% set override_deb_url=storage_base + override_deb %} {% endif %} </ins> {% if override_docker_ver != '' %} purge-old-docker-package: pkg.removed:

/var/cache/docker-install/{{ override_deb }}: file.managed: <del> - source: {{ storage_base }}{{ override_deb }} </del> <ins> - source: {{ override_deb_url }} </ins> - source_hash: sha1={{ override_deb_sha1 }} - user: root - group: root
Change:
The latest vagrant always restarts nfs when nfs is used to share folders: This doesn't work with the default kube libvirt image: Attempting to restart nfs (systemctl restart nfs) on this image results in a failure from /usr/sbin/exportfs (invoked in the nfs unit file via ExecStartPre) of 'No file systems exported!' and this halts vagrant provisioning. To replicate (centos 7.1+vagrant 1.8.1+vagrant-libvirt 0.0.32):
This issue should be resolved by (already merged) and .
I marked as lgtm, so its basically blocked by the submit queue being fixed.

Discussion:
if ! which /usr/libexec/cockpit-ws &>/dev/null; then pushd /etc/yum.repos.d <del> wget https://copr.fedoraproject.org/coprs/sgallagh/cockpit-preview/repo/fedora-22/sgallagh-cockpit-preview-fedora-22.repo </del> <ins> curl -OL https://copr.fedorainfracloud.org/coprs/g/cockpit/cockpit-preview/repo/fedora-23/msuchy-cockpit-preview-fedora-23.repo </ins> dnf install -y cockpit cockpit-kubernetes popd

if ! which salt-call >/dev/null 2>&1; then # Install salt binaries curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s <ins> # Fedora >= 23 includes salt packages but the bootstrap is # creating configuration for a (non-existent) salt repo anyway. # Remove the invalid repo to prevent dnf from warning about it on # every update.  Assume this problem is specific to Fedora 23 and # will fixed by the time another version of Fedora lands. local fedora_version=$(grep 'VERSION_ID' /etc/os-release | sed 's+VERSION_ID=++') if [[ "${fedora_version}" = '23' ]]; then local repo_file='/etc/yum.repos.d/saltstack-salt-fedora-23.repo' if [[ -f "${repo_file}" ]]; then rm "${repo_file}" fi fi </ins> fi }
Change:
Seeing a few instances of this in our Jenkins, e.g. This is maybe Go 1.5.3 related? not sure.
thanks for reporting this - will investigate , Jeff Grafton wrote:
This seems to have come back? From pull//kubernetes-pull-test-unit-integration//:
I'm seeing a flake here , totally unrelated to my change. FAIL 12.594s
This P0 has been open since Jan with little progress. Still valid?
We should at least remove p0 label
agree that this isn't p0. not sure how frequently this occurs.
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
fixed by , /cc .

Discussion:
for _, p := range lw.list.Items { if p.Name == name { <del> return &p </del> <ins> clone, err := api.Scheme.DeepCopy(&p) if err != nil { panic(err.Error()) } return clone.(*api.Pod) </ins> } } return nil } func (lw *MockPodsListWatch) Add(pod *api.Pod, notify bool) { <ins> clone, err := api.Scheme.DeepCopy(pod) if err != nil { panic(err.Error()) } pod = clone.(*api.Pod) </ins> func() { lw.lock.Lock() defer lw.lock.Unlock()

} } func (lw *MockPodsListWatch) Modify(pod *api.Pod, notify bool) { <ins> clone, err := api.Scheme.DeepCopy(pod) if err != nil { panic("failed to clone pod object") } pod = clone.(*api.Pod) </ins> found := false func() { lw.lock.Lock()
Change:
I disabled a block of code in . The code was flaky (). Suggest one of the following solutions: this type of test coverage to an e2e, or VM or docker based test, where there are no port conflicts. kubectl proxy command to have a mode where it will pick a port for you, trying until it finds one. the test loop to allow failure of kubectl proxy command when it exits with a certain error code that means it could not get a port, and retries until it gets one.
Fixed in ?
No, not fixed:
We still need to reenable this code. I was unaware that it'd been disabled.
I made a reversion PR.

Discussion:
PROXY_PORT_FILE= } # Starts "kubect proxy" to test the client proxy. $1: api_prefix function start-proxy() {

####################### # kubectl local proxy # ####################### <del> # This next block disabled until non-racy solution to # port allocation can be found (#19999). # #  # Make sure the UI can be proxied #  start-proxy #  check-curl-proxy-code /ui 301 #  check-curl-proxy-code /metrics 200 #  check-curl-proxy-code /api/ui 404 #  if [[ -n "${version}" ]]; then #    check-curl-proxy-code /api/${version}/namespaces 200 #  fi #  check-curl-proxy-code /static/ 200 #  stop-proxy # #  # Make sure the in-development api is accessible by default #  start-proxy #  check-curl-proxy-code /apis 200 #  check-curl-proxy-code /apis/extensions/ 200 #  stop-proxy # #  # Custom paths let you see everything. #  start-proxy /custom #  check-curl-proxy-code /custom/ui 301 #  check-curl-proxy-code /custom/metrics 200 #  if [[ -n "${version}" ]]; then #    check-curl-proxy-code /custom/api/${version}/namespaces 200 #  fi #  stop-proxy </del> <ins> # Make sure the UI can be proxied start-proxy check-curl-proxy-code /ui 301 check-curl-proxy-code /metrics 200 check-curl-proxy-code /api/ui 404 if [[ -n "${version}" ]]; then check-curl-proxy-code /api/${version}/namespaces 200 fi check-curl-proxy-code /static/ 200 stop-proxy # Make sure the in-development api is accessible by default start-proxy check-curl-proxy-code /apis 200 check-curl-proxy-code /apis/extensions/ 200 stop-proxy # Custom paths let you see everything. start-proxy /custom check-curl-proxy-code /custom/ui 301 check-curl-proxy-code /custom/metrics 200 if [[ -n "${version}" ]]; then check-curl-proxy-code /custom/api/${version}/namespaces 200 fi stop-proxy </ins> ########################### # POD creation / deletion #
Change:
Yet another case of not being deleted properly?
I can take a look in morning. Assign to me. I am blocked on generalizing the controller until the dynamic client is done. On Wednesday, February 10, 2016, Tim Hockin wrote:
Are you seeing this on HEAD? I had moved in a recent PR to call DeleteCollection instead of per item deletes. Possibly job has a bug there.
yes head , Derek Carr wrote:
- I see be bug. The list of version strings being passed to the controller got messed up in my last PR. I will send a patch soon.
I patched this into my cluster and it seems fixed, but the same problem exists for replicaset now.

Discussion:
glog.Fatalf("Failed to get supported resources from server: %v", err) } <del> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), &unversioned.APIVersions{}, s.NamespaceSyncPeriod) </del> <ins> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), versions, s.NamespaceSyncPeriod) </ins> go namespaceController.Run(s.ConcurrentNamespaceSyncs, wait.NeverStop) groupVersion := "extensions/v1beta1"

glog.Fatalf("Failed to get supported resources from server: %v", err) } <del> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), &unversioned.APIVersions{}, s.NamespaceSyncPeriod) </del> <ins> namespaceController := namespacecontroller.NewNamespaceController(clientset.NewForConfigOrDie(client.AddUserAgent(kubeconfig, "namespace-controller")), versions, s.NamespaceSyncPeriod) </ins> namespaceController.Run(s.ConcurrentNamespaceSyncs, wait.NeverStop) groupVersion := "extensions/v1beta1"
Change:
download- refers to release 1.1.4 but the latest is 1.1.7
Resolved by PR

Discussion:
} # k8s <del> KUBE_VERSION=${KUBE_VERSION:-"1.1.4"} </del> <ins> KUBE_VERSION=${KUBE_VERSION:-"1.1.7"} </ins> echo "Prepare kubernetes ${KUBE_VERSION} release ..." grep -q "^${KUBE_VERSION}$" binaries/.kubernetes 2>/dev/null || { curl -L https://github.com/kubernetes/kubernetes/releases/download/v${KUBE_VERSION}/kubernetes.tar.gz -o kubernetes.tar.gz
Change:
cc
Yet another failure
There is already fix in flight
Ok. I see
This was closed 5 days ago but appears to not be fixed. Many PRs have referenced it as a flake since the fix went in.
- I referenced to it 2 after it was closed, but all of those failures were from runs before this was merged. So it's possible that it's already fixed.
When was the fix merged? I saw this a couple hours ago:
Oops, same test but the error is slightly different... Maybe this is a seperate flake
Yeah - it seems to be something different.
Also - I'm not claiming it's definitely fixed - I just said that we need to double check, because the two that I linked was from before merge.
I'll close this one for now. Please reopen the issue and cc us if the flake occurs again.

Discussion:
// the test so we can ensure that we clean up after // ourselves defer podClient.Delete(pod.Name, api.NewDeleteOptions(0)) <del> _, err = podClient.Create(pod) </del> <ins> pod, err = podClient.Create(pod) </ins> if err != nil { Failf("Failed to create pod: %v", err) } By("verifying the pod is in kubernetes") <ins> selector = labels.SelectorFromSet(labels.Set(map[string]string{"time": value})) options = api.ListOptions{ LabelSelector:   selector, ResourceVersion: pod.ResourceVersion, } </ins> pods, err = podClient.List(options) if err != nil { Failf("Failed to query for pods: %v", err)