jiebi/CodeConvo huggingface dataset:
Code change:
"k8s.io/kubernetes/pkg/api/latest" "k8s.io/kubernetes/pkg/api/unversioned" client "k8s.io/kubernetes/pkg/client/unversioned" <ins> "k8s.io/kubernetes/pkg/labels" </ins> "k8s.io/kubernetes/pkg/util" "k8s.io/kubernetes/pkg/util/wait" )

Related discussion:
text: More detail can be seen in e2e test
cc
, Marek Grabowski wrote:
you are running an older version of the test. can you get the latest and try again ? This test had not failed at all yesterday in our automated test runs yesterday. Closing issue for now.
This failure depends on if the pod is really deleted and kube-proxy (the test container on) catch that the endpoint is deleted in 5s . After sending "delete pod" request for 5s, if the pod was still there and kube-proxy still contains this endpoints(this may happen under pressure), hit test can still detect 5 endpoints. At least we should ensure the pod was deleted. Anyway, I think will be helpful to this test. What do you think?
It doesn't matter if the pod is actually deleted or not. We just care that kube-proxy thinks that it should not be part of the service endpoint. Having said that, it still doesn't hurt to do the check that you are doing. I will assign your PR to myself and review it. In the meantime, can you rebase your PR ?
Thanks for your review. The PR is up to date.
Failed twice today in kubernetes-e2e-gce-parallel
One more today. The error message is not very helpful.
18:28:37 STEP: dialing(http) endpointPodIP:endpointHttpPort from node1 18:28:37 STEP: Dialing from node. command:for i in ' wc -l This is the point where the test fails. Am looking into it. We need to have more tries, we just do seq (1 1), instead of seq (6 6). this is causing flakiness.
Fixed by PR
Code change:
Container Runtime Conformance Test container runtime conformance blackbox test when starting a container that exits should report termination message if TerminationMessagePath is set,timothysc,1 DNS horizontal autoscaling kube-dns-autoscaler should scale kube-dns pods in both nonfaulty and faulty scenarios,MrHohn,0 DNS horizontal autoscaling kube-dns-autoscaler should scale kube-dns pods when cluster size changed,MrHohn,0 <ins> ContainerLogPath Pod with a container printed log to stdout should print log to correct log path,resouer,0 </ins> DNS should provide DNS for ExternalName services,rmmh,1 DNS should provide DNS for pods for Hostname and Subdomain Annotation,mtaufen,1 DNS should provide DNS for services,roberthbailey,1

Related discussion:
text: Cluster logging assumes kubelet stores container log at a specific directory with specific name. Currently the path is: After the CRI work, the path will be: However, we don't have test coverage for this. We don't even know whether the log files are there or not. We should add a node e2e test for this, basically: 1) Create a container which prints logs 2) Check whether the expected log file is created. 3) Check whether the logs are collected in the file as expected. And it would be better to launch a pod to do the check instead of accessing local file system directly, which makes containerizing easier. /cc because you are collecting missing test. /cc
I will try to add a node-e2e test there
I think it's ok to add this for CRI. But there maybe problems on today's interface for rkt. If I'm not wrong, rkt does't store logs at same location with docker. cc/ Is this true?
Thanks! :)
After gets merged, we need to update the test to verify the cri log path.
Code change:
sed -i'' -e "s@{{kubemark_image_registry}}@${KUBEMARK_IMAGE_REGISTRY}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" sed -i'' -e "s@{{kubemark_image_tag}}@${KUBEMARK_IMAGE_TAG}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" sed -i'' -e "s@{{master_ip}}@${MASTER_IP}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" <del> sed -i'' -e "s@{{hollow_kubelet_params}}@${HOLLOW_KUBELET_TEST_ARGS}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" sed -i'' -e "s@{{hollow_proxy_params}}@${HOLLOW_PROXY_TEST_ARGS}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" </del> <ins> sed -i'' -e "s@{{hollow_kubelet_params}}@${hollow_kubelet_params}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" sed -i'' -e "s@{{hollow_proxy_params}}@${hollow_proxy_params}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" </ins> sed -i'' -e "s@{{kubemark_mig_config}}@${KUBEMARK_MIG_CONFIG:-}@g" "${RESOURCE_DIRECTORY}/hollow-node.yaml" "${KUBECTL}" create -f "${RESOURCE_DIRECTORY}/hollow-node.yaml" --namespace="kubemark"

Related discussion:
text: There are CVEs happening in different images - we already migrated Kubmeark from busybox in , but we should go one step further and migrate the base image to distroless. There are some things that would need to be changed mentioned here: /sig scalability
Can I work on this? /assign
/remove-help
- sure that would be great.
Hi based on the discussion in , the kubemark image has dependency on and maybe more other utilities. So it seems impossible to migrate the base image to distroless? Or do we need something like debian-hyperkube-base?
The mount one we may get rid of - basically we should be able to switch to FakeMounter:
Code change:
Containers: []v1.Container{ { Name:  "nfs-provisioner", <del> Image: "quay.io/kubernetes_incubator/nfs-provisioner:v2.2.0-k8s1.12", </del> <ins> Image: "quay.io/kubernetes_incubator/nfs-provisioner:v2.2.2", </ins> SecurityContext: &v1.SecurityContext{ Capabilities: &v1.Capabilities{ Add: []v1.Capability{"DAC_READ_SEARCH"},

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-enabled-default Which test(s) are failing: CSI hostpath-v0 tests Since when has it been failing: 8/8 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: We need to update client-go to get the fix for selfLink, build new nfs provisioner images, and update them in the e2e test. The fix for client-go is being cherry-picked to 1.15 if you want to use a tagged release:
/assign
/assign
This implies rebase to 1.15.x in external-storage, which seem to be challenging (at least to me :-) )
14 cherry pick also in progress:
OK, I guess this line in the lib is the culprit: So I need to update lib then external-storage to pull it in
I don't think the lib itself needs to be updated. Only updating go-client to get the fix to is needed.
Right, lib doesn't dictate what version of client-go to use. Will wait for client-go release/commit
- thanks a lot for bumping the dependency. Did you have a chance to build the new container with it so that we could update it here:
yeah, opened . (Not sure how to trigger test, or we can just merge and see.)
You can manually create a PVC on an alpha cluster to test.
Code change:
testReadFile(input.f, input.filePathInSubpath, input.pod, 0) }) <del> It("should fail for new directories when readOnly specified in the volumeSource [Slow]", func() { if input.roVol == nil { framework.Skipf("Volume type %v doesn't support readOnly source", input.volType) } // Format the volume while it's writable formatVolume(input.f, input.formatPod) // Set volume source to read only input.pod.Spec.Volumes[0].VolumeSource = *input.roVol // Pod should fail testPodFailSubpathError(input.f, input.pod, "") }) </del> // TODO: add a test case for the same disk with two partitions }

Related discussion:
text: xref: When running the GCE PD CSI Driver against all dynamic provisioning tests from this PR: We encounter the following test failures that need to be resolved: /kind bug /sig storage /cc
So it seems that the flag is getting passed all the way through to the driver and it is behaving as we would expect it to in terms of mounting. All the correct commands are being run: When exec-ing into the gce-pd-driver container we can observe that the mounted point is indeed read only. However, when viewed from the host node's perspective the mount is still read write. And therefore since the subpath folder is created by the host, the folder is still being created successfully which fails the test. This behavior suggests that is either not properly propagating the read only option on remount, or not properly remounting at all. I can't figure out how to "view mount events" if that's even possible, some help would be appreciated if anyone is aware of how to do that. That would help me narrrow down which of those two options is happening. I have also attempted (from inside the gce pd driver container) to unmount the point (successful) and bind mount it back with the readonly option directly (not using remount trick, still unsuccessful). Suggesting that maybe it is the that is not being mount propagated and not a problem with in particular. /cc
/assign
/milestone v1.13 /priority important-soon
Code change:
priorityClassName: system-node-critical hostNetwork: true nodeSelector: <del> # TODO(liggitt): switch to node.kubernetes.io/kube-proxy-ds-ready in 1.16 beta.kubernetes.io/kube-proxy-ds-ready: "true" </del> <ins> node.kubernetes.io/kube-proxy-ds-ready: "true" </ins> tolerations: - operator: "Exists" effect: "NoExecute"

Related discussion:
text: xref In 1.16: change the metadata-proxy addon to use change the kube-proxy addon to use change the masq-agent addon to use stop setting , , and in kube-up
Hey I'm trying to start to contribute to kubernetes and this seem to be an easy task. Can I help with this one?
Code change:
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/

Related discussion:
text: and provide for configuring Flannel's parameter but none of the others listed in
Code change:
return oomScoreAdj } <del> // getCachedVersionInfo gets cached version info of docker runtime. func (dm *DockerManager) getCachedVersionInfo() (kubecontainer.Version, kubecontainer.Version, error) { apiVersion, daemonVersion, err := dm.versionCache.Get(dm.machineInfo.MachineID) if err != nil { glog.Errorf("Failed to get cached docker api version %v ", err) } // If we got nil versions, try to update version info. if apiVersion == nil || daemonVersion == nil { dm.versionCache.Update(dm.machineInfo.MachineID) } return apiVersion, daemonVersion, err } </del> // checkDockerAPIVersion checks current docker API version against expected version. // Return: // 1 : newer than expected version // -1: older than expected version // 0 : same version func (dm *DockerManager) checkDockerAPIVersion(expectedVersion string) (int, error) { <del> apiVersion, _, err := dm.getCachedVersionInfo() </del> <ins> apiVersion, _, err := dm.getVersionInfo() </ins> if err != nil { return 0, err }

Related discussion:
text: The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.
Code change:
<del> amd64=fedora:28 arm64=arm64v8/fedora:28 ppc64le=ppc64le/fedora:28 </del> <ins> amd64=fedora:26 arm64=arm64v8/fedora:26 ppc64le=ppc64le/fedora:26 </ins>

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e tests which use RBD server image fail with What you expected to happen: These tests succeed. How to reproduce it (as minimally and precisely as possible): Run e2e tests which use RBD server image. Anything else we need to know?: /sig storage This issue is introduced by below commit: It change the base image from fedora 26 to fedora 28. In fedora 26, hostname command is installed as a dependency for  However, in fedora 28, it is not installed, as a result, this issue happens due to lack of hostname command. Environment: Kubernetes version (use ): k8s 1.12 alpha
Please see the difference of the behaviour between fedora 26 and 28. [Fedora26] [Fedora28]
Could you help solving this issue? I assume the fix for the code would be as below, but I'm not familiar with the build and push process for the test image. ( in doesn't work.) So, I need your help to make further progress.
(or) Both need to be run from directory
Thank you for letting me know it. It should be s/all-containers/all-container/, but it seems to work. I will test with above patch and above build commands, then make a PR, once I confirm that it works well.
sorry typing from memory :)
I need to ask you two more things: Do we need to increment the version for this image, like 1.0.1, even for this small change? (I guess that and test/images/volume/rbd/VERSION will need to be updated in this case.) How the image push process will be? Does it pushed by CI, if there are a change in the code or docker file, or do someone who have permission will push it manually?
creates below three docker images: Is my understanding right that to make each test access to each arch image, needs to be modified like below? (Without doing so, each test seems to keep trying to access to , without arch.)
For fedora28 image, just installing hostname doesn't seem to work well. Please see the log below and attached . I guess that this is due to the difference of ceph version, which will be beyond my beyond my expertise.
Code change:
<del> amd64=fedora:28 arm64=arm64v8/fedora:28 ppc64le=ppc64le/fedora:28 </del> <ins> amd64=fedora:26 arm64=arm64v8/fedora:26 ppc64le=ppc64le/fedora:26 </ins>

Related discussion:
text: So, could you help debugging this issue? Meanwhile, I will try testing with the image by using fedora26 for workaround.
I confirmed that below commit, which change the base image back to fedora 26, fix this issue. Please see the log . After I checked the image-, I come to think that by pushing the image, each image will be able to be pulled without -arch, so I guess the last parameter for ImageConfig should be false. (I couldn't test it in my environment.) I will fix the commit as so and make a PR once I confirm it. Also, if it will easy to fix with Fedora 28, I will wait for the actual fix and quit making a PR for the workaround.
thanks yes, a quick fix is welcome, looking forward
Thank you for your comment. I will continue with the workaround. I saw a commit for deleting multi arch consideration. I rebased the patch to the commit and made a PR. Please review it.
Code change:
client, ns, labels.SelectorFromSet(labels.Set(rc.Spec.Selector))) } } <ins> func getPodLogs(c *client.Client, namespace, podName, containerName string) (string, error) { return getPodLogsInternal(c, namespace, podName, containerName, false) } func getPreviousPodLogs(c *client.Client, namespace, podName, containerName string) (string, error) { return getPodLogsInternal(c, namespace, podName, containerName, true) } // utility function for gomega Eventually func getPodLogsInternal(c *client.Client, namespace, podName, containerName string, previous bool) (string, error) { logs, err := c.Get(). Resource("pods"). Namespace(namespace). Name(podName).SubResource("log"). Param("container", containerName). Param("previous", strconv.FormatBool(previous)). Do(). Raw() if err != nil { return "", err } if err == nil && strings.Contains(string(logs), "Internal Error") { return "", fmt.Errorf("Fetched log contains "Internal Error": %q.", string(logs)) } return string(logs), err } </ins>

Related discussion:
text: We are running heapster, dns server, kube-proxy etc. in kube-system namespace. Some e2e tests try to make sure all those kube-system pods are at ready state before firing the real tests, others just simply ingore them. But both cases might cause e2e flakiness when some of those kube-system containers are in crashloop, for example, for heapster crashloop, for influxdb crashloop, etc. When such cases happen, the developer doesn't have much information on why since the nodes might be teared down. We should watch those kube-system pods, and onContainerFailure, we should collect the related logs. One simple way is using kubectl logs <Pod<Container--previous cc/
is this related enough to and that you can bundle it in?
The logs from the pods should be retrieved via the api server. This is different from the kubelet logs. I'll upload a PR for this.
Great job It will be very helpful for debugging.
Code change:
t *testing.T, expectedAttachCallCount int, fakePlugin *volumetesting.FakeVolumePlugin) { <del> if len(fakePlugin.Attachers) == 0 && expectedAttachCallCount == 0 { </del> <ins> if len(fakePlugin.GetAttachers()) == 0 && expectedAttachCallCount == 0 { </ins> return } err := retryWithExponentialBackOff( time.Duration(5*time.Millisecond), func() (bool, error) { <del> for i, attacher := range fakePlugin.Attachers { </del> <ins> for i, attacher := range fakePlugin.GetAttachers() { </ins> actualCallCount := attacher.GetAttachCallCount() if actualCallCount == expectedAttachCallCount { return true, nil

Related discussion:
text: Looks like similar issue with
That's the PV controller this is the attach controller, thus separate issues.
Code change:
) const ( <del> probeTimeOut = time.Minute </del> <ins> probeTimeOut = 20 * time.Second </ins> ) // TODO: this basic interface is duplicated in N places.  consolidate?

Related discussion:
text: this job failed with It seems it is imssing some dependency The job history confirms it is totally broken Originally posted by in
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig testing
Code change:
rbdImageSizeUnitMiB      = 1024 * 1024 ) <ins> // A struct contains rbd image info. type rbdImageInfo struct { pool string name string } </ins> func getDevFromImageAndPool(pool, image string) (string, bool) { device, found := getRbdDevFromImageAndPool(pool, image) if found {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Pod was deleted successfully but there is still a lock on the ceph image. I find two logs,one for that lock not removed and another for that lock removed. I find that there are little difference between them. the log that lock not removed: and the log that lock removed: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.6.7 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): centos7 Kernel (e.g. ): 3.10.0-327.el7.x86_64 Install tools: Others:
/sig storage
Error 16 is EBUSY. similar to
were you running kubelet with cadvisor on?
/assign
yes, every kubelet run with cadvisor,and i know what code 16 represent for,but i still don't know the reason, is this a bug? How can i avoid this kind of situation from happening,thank you
It is probably related to
We see some other case may cause , kubelet run with nodeexporter and nodeexporter is deployed by k8s daemonset with -v /:/rootfs:ro (mount kubelet host rootfs into nodeexporter container). rbd device is mounted before nodeexporter started, because k8s 1.6.7 not support mount propagation, when the rbd plugin unmount /dev/rbd0 on the host namespace, the mount info will still leave over in node_exporter container namespace, may cause . hope this would help
thanks, does the problem persist if node_exporter stops collecting filesystem metrics?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with .
Code change:
rbdImageSizeUnitMiB      = 1024 * 1024 ) <ins> // A struct contains rbd image info. type rbdImageInfo struct { pool string name string } </ins> func getDevFromImageAndPool(pool, image string) (string, bool) { device, found := getRbdDevFromImageAndPool(pool, image) if found {

Related discussion:
text: Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
I'm experiencing this issue. From what I can read above, if the rbd mount happens before the node_exporter starts; we'll always experience status 16?
We're getting this issue. This is because the mounted volume is mounted on Cadvisor container too. So the /dev/rbdX file is still in use. But still didn't find any solution to fix.
rbd volume will stuck when failed as will always returen
My solution: container use a volumeMount. make a script file to be executed every a minute: