Question:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --k8s-e2e-ltsc2019-containerd-flannel-sdnoverlay-master [] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestart http hook properly [NodeConformance] [Conformance] [] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart http hook properly [NodeConformance] [Conformance] Note: the tests have been excluded until they are fixed. In the case of multinode clusters, the http server pod and the test cluster can spawn on different nodes, which can be problematic for poststart / prestop hooks, as they are executed by the kubelet itself, and the cross-node lifecycle hook might fail (according to the [Kubernetes network model], it is not mandatory for kubelet to be able to access pods on a different node). However, that is not always the case, different Networking setups allow cross-node communication between kubelet and pods, which means that the above tests are passing properly (for example: ), which begs the question if this behaviour should be universal or not, especially since the tests are marked as , which would imply that it should work in all cases. [Kubernetes network model]: links to appreciated links to specific failures in spyglass appreciated Slack: /sig testing /sig networking /sig windows <!-- Please see the deflaking doc () for more guidance! --
/sig network /sig node /area conformance /assign /priority critical-urgent /cc This is important since affects conformance and defines the networking behaviour for the poststart/ prestop hooks
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig node /sig conformance /assign /priority critical-urgent /cc Instructions 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
i'd personally let folks have first dibs on what we need to do here. Though from the name of the test itself, it seems like the test is NOT a sig-network test :)
Indeed, it does not have any tag in its name, but the tests rely on networking and on how CNIs work. As I've stated above, it's not a problem for flannel sdnbridge, but it is for flannel sdnoverlay; other CNIs might have a similar issue too.
because the network is not a thing :) let´s tag the sig owner then /sig node I think that the key here is to decide if kubelet should be able to access pod in other nodes, and based on the link Claudiu is part of the Kubernetes networking model. I saw users that doesn't want kubelet to access even the pods on same host, so I think that is legit to say kubelet MAY reach pods in other nodes but not MUST ... but I'm not familiar with the to fully understand the context. If kubelet "may" reach pods in the other nodes, the test must only test lifecycle hooks for pods in the same node as the kubelet under test, right?
This is correct. The model also says: "For those platforms that support Pods running in the host network (e.g. Linux): pods in the host network of a node can communicate with all pods on all nodes without NAT" I believe that Windows host network is not supported, right?
Right, and there are specific tests that checks that exact scenario you've mentioned: However, the flaky tests I've mentioned in the issue require kubelet to be able to dial-in into a webserver pod for a different pod's poststart / prestop HTTP lifecycle hooks. There are couple of things regarding this: of all, in order to ensure kubelet would be able to run the HTTP lifecycle hooks, we'd have to make sure both pods are on the same node, as that is a supported scenario, according to the Kubernetes Network Model. I have sent a PR for this above. Alternatively, a Cluster IP could probably work as well, but IMO, ensuring that both pods end up on the same node is simpler and easier to clean up. , it's interesting that those HTTP lifecycle hook tests work on different networking setups, without any pods having HostNetwork enabled, even though you've mentioned they should (e.g.: Linux / Windows with flannel l2bridge, and even Linux with flannel overlay). Now, my question is: is this behaviour a feature, or a bug, especially since the tests are marked as `?
oh, I missed that part, so in Linux kubelet must be able to communicate with pods on all nodes (becuase it is running in the hostnetwork) If that is correct, it seems that one solution is to keep the test for Linux and tag it as LinuxOnly, and a new test for WindowsOnly that only spawn the pods under test in the same node EDIT Discussed in sig-net meeting , no clear answer... can be kubelet considered as a hostnetwork pod?
For the purposes of testing, I don't mind forcing the pods onto the same node., but let's document the heck out of that at the code-site?
correct but it will be supported once HostProcess containers are merged in 1.22: Only in Overlay networks (ie Flannel where these tests are flaking) does the pod have to be on the same node. It doesn't require host network mode and these tests are . I would be more inclined to disable this test for Windows Overlay test setups and have a sig-windows test for the overlay functionality. I would also question if the lifecycle hooks only running on the same node is useful and if it should just be documented that it doesn't work in the Windows Overlay setup.
is looking at test PRs from SIG Node. I will let sig-net triage this issue
Next steps on this?
/triage accepted
We still haven't merged this: I also had this, but it has been decided to be blocked:
requires conformance approval, at this point I think that has to be postponed to 1.23 right, since that behavior is not required, we shouldn't test it, because is legit to fail and having a test for something that can fail can create confusion :smile:

/* Release: v1.9 Testname: Pod Lifecycle, post start http hook <del> Description: When a post start handler is specified in the container lifecycle using a HttpGet action, then the handler MUST be invoked after the start of the container. A server pod is created that will serve http requests, create a second pod with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </del> <ins> Description: When a post start handler is specified in the container lifecycle using a HttpGet action, then the handler MUST be invoked after the start of the container. A server pod is created that will serve http requests, create a second pod on the same node with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </ins> */ framework.ConformanceIt("should execute poststart http hook properly [NodeConformance]", func() { lifecycle := &v1.Lifecycle{


Question:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --k8s-e2e-ltsc2019-containerd-flannel-sdnoverlay-master [] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestart http hook properly [NodeConformance] [Conformance] [] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart http hook properly [NodeConformance] [Conformance] Note: the tests have been excluded until they are fixed. In the case of multinode clusters, the http server pod and the test cluster can spawn on different nodes, which can be problematic for poststart / prestop hooks, as they are executed by the kubelet itself, and the cross-node lifecycle hook might fail (according to the [Kubernetes network model], it is not mandatory for kubelet to be able to access pods on a different node). However, that is not always the case, different Networking setups allow cross-node communication between kubelet and pods, which means that the above tests are passing properly (for example: ), which begs the question if this behaviour should be universal or not, especially since the tests are marked as , which would imply that it should work in all cases. [Kubernetes network model]: links to appreciated links to specific failures in spyglass appreciated Slack: /sig testing /sig networking /sig windows <!-- Please see the deflaking doc () for more guidance! --
/sig network /sig node /area conformance /assign /priority critical-urgent /cc This is important since affects conformance and defines the networking behaviour for the poststart/ prestop hooks
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig node /sig conformance /assign /priority critical-urgent /cc Instructions 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
i'd personally let folks have first dibs on what we need to do here. Though from the name of the test itself, it seems like the test is NOT a sig-network test :)
Indeed, it does not have any tag in its name, but the tests rely on networking and on how CNIs work. As I've stated above, it's not a problem for flannel sdnbridge, but it is for flannel sdnoverlay; other CNIs might have a similar issue too.
because the network is not a thing :) let´s tag the sig owner then /sig node I think that the key here is to decide if kubelet should be able to access pod in other nodes, and based on the link Claudiu is part of the Kubernetes networking model. I saw users that doesn't want kubelet to access even the pods on same host, so I think that is legit to say kubelet MAY reach pods in other nodes but not MUST ... but I'm not familiar with the to fully understand the context. If kubelet "may" reach pods in the other nodes, the test must only test lifecycle hooks for pods in the same node as the kubelet under test, right?
This is correct. The model also says: "For those platforms that support Pods running in the host network (e.g. Linux): pods in the host network of a node can communicate with all pods on all nodes without NAT" I believe that Windows host network is not supported, right?
Right, and there are specific tests that checks that exact scenario you've mentioned: However, the flaky tests I've mentioned in the issue require kubelet to be able to dial-in into a webserver pod for a different pod's poststart / prestop HTTP lifecycle hooks. There are couple of things regarding this: of all, in order to ensure kubelet would be able to run the HTTP lifecycle hooks, we'd have to make sure both pods are on the same node, as that is a supported scenario, according to the Kubernetes Network Model. I have sent a PR for this above. Alternatively, a Cluster IP could probably work as well, but IMO, ensuring that both pods end up on the same node is simpler and easier to clean up. , it's interesting that those HTTP lifecycle hook tests work on different networking setups, without any pods having HostNetwork enabled, even though you've mentioned they should (e.g.: Linux / Windows with flannel l2bridge, and even Linux with flannel overlay). Now, my question is: is this behaviour a feature, or a bug, especially since the tests are marked as `?
oh, I missed that part, so in Linux kubelet must be able to communicate with pods on all nodes (becuase it is running in the hostnetwork) If that is correct, it seems that one solution is to keep the test for Linux and tag it as LinuxOnly, and a new test for WindowsOnly that only spawn the pods under test in the same node EDIT Discussed in sig-net meeting , no clear answer... can be kubelet considered as a hostnetwork pod?
For the purposes of testing, I don't mind forcing the pods onto the same node., but let's document the heck out of that at the code-site?
correct but it will be supported once HostProcess containers are merged in 1.22: Only in Overlay networks (ie Flannel where these tests are flaking) does the pod have to be on the same node. It doesn't require host network mode and these tests are . I would be more inclined to disable this test for Windows Overlay test setups and have a sig-windows test for the overlay functionality. I would also question if the lifecycle hooks only running on the same node is useful and if it should just be documented that it doesn't work in the Windows Overlay setup.
is looking at test PRs from SIG Node. I will let sig-net triage this issue
Next steps on this?
/triage accepted
We still haven't merged this: I also had this, but it has been decided to be blocked:
requires conformance approval, at this point I think that has to be postponed to 1.23 right, since that behavior is not required, we shouldn't test it, because is legit to fail and having a test for something that can fail can create confusion :smile:

}, } podWithHook := getPodWithHook("pod-with-poststart-http-hook", imageutils.GetPauseImageName(), lifecycle) <ins> // make sure we spawn the test pod on the same node as the webserver. nodeSelection := e2epod.NodeSelection{} e2epod.SetAffinity(&nodeSelection, targetNode) e2epod.SetNodeSelection(&podWithHook.Spec, nodeSelection) </ins> testPodWithHook(podWithHook) }) /* Release: v1.9 Testname: Pod Lifecycle, prestop http hook <del> Description: When a pre-stop handler is specified in the container lifecycle using a 'HttpGet' action, then the handler MUST be invoked before the container is terminated. A server pod is created that will serve http requests, create a second pod with a container lifecycle specifying a pre-stop that invokes the server pod to validate that the pre-stop is executed. </del> <ins> Description: When a pre-stop handler is specified in the container lifecycle using a 'HttpGet' action, then the handler MUST be invoked before the container is terminated. A server pod is created that will serve http requests, create a second pod on the same node with a container lifecycle specifying a pre-stop that invokes the server pod to validate that the pre-stop is executed. </ins> */ framework.ConformanceIt("should execute prestop http hook properly [NodeConformance]", func() { lifecycle := &v1.Lifecycle{


Question:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --k8s-e2e-ltsc2019-containerd-flannel-sdnoverlay-master [] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestart http hook properly [NodeConformance] [Conformance] [] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart http hook properly [NodeConformance] [Conformance] Note: the tests have been excluded until they are fixed. In the case of multinode clusters, the http server pod and the test cluster can spawn on different nodes, which can be problematic for poststart / prestop hooks, as they are executed by the kubelet itself, and the cross-node lifecycle hook might fail (according to the [Kubernetes network model], it is not mandatory for kubelet to be able to access pods on a different node). However, that is not always the case, different Networking setups allow cross-node communication between kubelet and pods, which means that the above tests are passing properly (for example: ), which begs the question if this behaviour should be universal or not, especially since the tests are marked as , which would imply that it should work in all cases. [Kubernetes network model]: links to appreciated links to specific failures in spyglass appreciated Slack: /sig testing /sig networking /sig windows <!-- Please see the deflaking doc () for more guidance! --
/sig network /sig node /area conformance /assign /priority critical-urgent /cc This is important since affects conformance and defines the networking behaviour for the poststart/ prestop hooks
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig node /sig conformance /assign /priority critical-urgent /cc Instructions 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
i'd personally let folks have first dibs on what we need to do here. Though from the name of the test itself, it seems like the test is NOT a sig-network test :)
Indeed, it does not have any tag in its name, but the tests rely on networking and on how CNIs work. As I've stated above, it's not a problem for flannel sdnbridge, but it is for flannel sdnoverlay; other CNIs might have a similar issue too.
because the network is not a thing :) let´s tag the sig owner then /sig node I think that the key here is to decide if kubelet should be able to access pod in other nodes, and based on the link Claudiu is part of the Kubernetes networking model. I saw users that doesn't want kubelet to access even the pods on same host, so I think that is legit to say kubelet MAY reach pods in other nodes but not MUST ... but I'm not familiar with the to fully understand the context. If kubelet "may" reach pods in the other nodes, the test must only test lifecycle hooks for pods in the same node as the kubelet under test, right?
This is correct. The model also says: "For those platforms that support Pods running in the host network (e.g. Linux): pods in the host network of a node can communicate with all pods on all nodes without NAT" I believe that Windows host network is not supported, right?
Right, and there are specific tests that checks that exact scenario you've mentioned: However, the flaky tests I've mentioned in the issue require kubelet to be able to dial-in into a webserver pod for a different pod's poststart / prestop HTTP lifecycle hooks. There are couple of things regarding this: of all, in order to ensure kubelet would be able to run the HTTP lifecycle hooks, we'd have to make sure both pods are on the same node, as that is a supported scenario, according to the Kubernetes Network Model. I have sent a PR for this above. Alternatively, a Cluster IP could probably work as well, but IMO, ensuring that both pods end up on the same node is simpler and easier to clean up. , it's interesting that those HTTP lifecycle hook tests work on different networking setups, without any pods having HostNetwork enabled, even though you've mentioned they should (e.g.: Linux / Windows with flannel l2bridge, and even Linux with flannel overlay). Now, my question is: is this behaviour a feature, or a bug, especially since the tests are marked as `?
oh, I missed that part, so in Linux kubelet must be able to communicate with pods on all nodes (becuase it is running in the hostnetwork) If that is correct, it seems that one solution is to keep the test for Linux and tag it as LinuxOnly, and a new test for WindowsOnly that only spawn the pods under test in the same node EDIT Discussed in sig-net meeting , no clear answer... can be kubelet considered as a hostnetwork pod?
For the purposes of testing, I don't mind forcing the pods onto the same node., but let's document the heck out of that at the code-site?
correct but it will be supported once HostProcess containers are merged in 1.22: Only in Overlay networks (ie Flannel where these tests are flaking) does the pod have to be on the same node. It doesn't require host network mode and these tests are . I would be more inclined to disable this test for Windows Overlay test setups and have a sig-windows test for the overlay functionality. I would also question if the lifecycle hooks only running on the same node is useful and if it should just be documented that it doesn't work in the Windows Overlay setup.
is looking at test PRs from SIG Node. I will let sig-net triage this issue
Next steps on this?
/triage accepted
We still haven't merged this: I also had this, but it has been decided to be blocked:
requires conformance approval, at this point I think that has to be postponed to 1.23 right, since that behavior is not required, we shouldn't test it, because is legit to fail and having a test for something that can fail can create confusion :smile:

}, } podWithHook := getPodWithHook("pod-with-prestop-http-hook", imageutils.GetPauseImageName(), lifecycle) <ins> // make sure we spawn the test pod on the same node as the webserver. nodeSelection := e2epod.NodeSelection{} e2epod.SetAffinity(&nodeSelection, targetNode) e2epod.SetNodeSelection(&podWithHook.Spec, nodeSelection) </ins> testPodWithHook(podWithHook) }) })


Question:
kubelet logs misleading when volume limits not an
/sig storage /tirage accepted /assign
Note that it is set as info level in the log above: However, this is definitely confusing. /remove-kind bug /kind cleanup /triage accepted /sig node
I also have this problem Excuse me, how did you solve it
Which version do you use .. This was fixed here Check k8s version you use please

for _, volumePlugin := range pluginWithLimits { attachLimits, err := volumePlugin.GetVolumeLimits() if err != nil { <del> klog.V(4).InfoS("Error getting volume limit for plugin", "plugin", volumePlugin.GetPluginName()) </del> <ins> klog.V(4).InfoS("Skipping volume limits for volume plugin", "plugin", volumePlugin.GetPluginName()) </ins> continue } for limitKey, value := range attachLimits {


Question:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

err := cs.CoreV1().Services(ns).Delete(context.TODO(), serviceName, metav1.DeleteOptions{}) framework.ExpectNoError(err, "failed to delete service: %s in namespace: %s", serviceName, ns) }() <del> _, err := jig.CreateTCPServiceWithPort(nil, 80) </del> <ins> svc, err := jig.CreateTCPServiceWithPort(nil, 80) </ins> framework.ExpectNoError(err) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{})


Question:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

name1 := "pod1" name2 := "pod2" <del> createPodOrFail(f, ns, name1, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}) </del> <ins> createPodOrFail(f, ns, name1, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}, "netexec", "--http-port", "80") </ins> names[name1] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name1: {80}}) <del> createPodOrFail(f, ns, name2, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}) </del> <ins> ginkgo.By("Checking if the Service forwards traffic to pod1") execPod := e2epod.CreateExecPodOrFail(cs, ns, "execpod", nil) err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) createPodOrFail(f, ns, name2, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}, "netexec", "--http-port", "80") </ins> names[name2] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name1: {80}, name2: {80}}) <ins> ginkgo.By("Checking if the Service forwards traffic to pod1 and pod2") err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) </ins> e2epod.DeletePodOrFail(cs, ns, name1) delete(names, name1) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name2: {80}}) <ins> ginkgo.By("Checking if the Service forwards traffic to pod2") err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) </ins> e2epod.DeletePodOrFail(cs, ns, name2) delete(names, name2) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{})


Question:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

svc2port := "svc2" ginkgo.By("creating service " + serviceName + " in namespace " + ns) <del> _, err := jig.CreateTCPService(func(service *v1.Service) { </del> <ins> svc, err := jig.CreateTCPService(func(service *v1.Service) { </ins> service.Spec.Ports = []v1.ServicePort{ { Name:       "portname1",


Question:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

podname1 := "pod1" podname2 := "pod2" <del> createPodOrFail(f, ns, podname1, jig.Labels, containerPorts1) </del> <ins> createPodOrFail(f, ns, podname1, jig.Labels, containerPorts1, "netexec", "--http-port", strconv.Itoa(port1)) </ins> names[podname1] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{podname1: {port1}}) <del> createPodOrFail(f, ns, podname2, jig.Labels, containerPorts2) </del> <ins> createPodOrFail(f, ns, podname2, jig.Labels, containerPorts2, "netexec", "--http-port", strconv.Itoa(port2)) </ins> names[podname2] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{podname1: {port1}, podname2: {port2}}) <ins> ginkgo.By("Checking if the Service forwards traffic to pods") execPod := e2epod.CreateExecPodOrFail(cs, ns, "execpod", nil) err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) </ins> e2epod.DeletePodOrFail(cs, ns, podname1) delete(names, podname1) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{podname2: {port2}})


Question:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

} // createPodOrFail creates a pod with the specified containerPorts. <del> func createPodOrFail(f *framework.Framework, ns, name string, labels map[string]string, containerPorts []v1.ContainerPort) { </del> <ins> func createPodOrFail(f *framework.Framework, ns, name string, labels map[string]string, containerPorts []v1.ContainerPort, args ...string) { </ins> ginkgo.By(fmt.Sprintf("Creating pod %s in namespace %s", name, ns)) <del> pod := e2epod.NewAgnhostPod(ns, name, nil, nil, containerPorts) </del> <ins> pod := e2epod.NewAgnhostPod(ns, name, nil, nil, containerPorts, args...) </ins> pod.ObjectMeta.Labels = labels // Add a dummy environment variable to work around a docker issue. // https://github.com/docker/docker/issues/14203


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --post-kubernetes-push-e2e-agnhost-test-images Image build unhappy on s390x arch: Building image for agnhost OS/ARCH: linux/s390x... [...] [ 3/10] RUN apk --update add bind-tools curl netcat-openbsd iproute2 ipe... 0.165 fetch http://dl- 0.725 fetch http://dl- 1.719 (1/35) Installing ncurses-terminfo-base (6.2p20200523-r0) 1.758 (2/35) Installing ncurses-libs (6.2p20200523-r0) 1.811 (3/35) Installing readline (8.0.4-r0) 1.851 (4/35) Installing bash (5.0.17-r0) 1.939 Executing bash-5.0.17- 1.945 ERROR: bash-5.0.17- script exited with error 1 1.945 (5/35) Installing fstrm (0.6.0-r1) 1.987 (6/35) Installing libgcc (9.3.0-r2) 2.013 (7/35) Installing krb5-conf (1.0-r2) 2.053 (8/35) Installing libcomerr (1.45.6-r0) 2.093 (9/35) Installing keyutils-libs (1.6.1-r1) 2.133 (10/35) Installing libverto (0.3.1-r1) 2.174 (11/35) Installing krb5-libs (1.18.3-r0) 2.334 (12/35) Installing json-c (0.14-r1) 2.376 (13/35) Installing libstdc++ (9.3.0-r2) 2.493 (14/35) Installing libprotobuf (3.12.2-r0) 2.667 (15/35) Installing libprotoc (3.12.2-r0) 2.807 (16/35) Installing protobuf-c (1.3.3-r1) 2.854 (17/35) Installing libuv (1.38.1-r0) 2.906 (18/35) Installing xz-libs (5.2.5-r0) 2.954 (19/35) Installing libxml2 (2.9.10-r5) 3.071 (20/35) Installing bind-libs (9.16.15-r0) 3.287 (21/35) Installing bind-tools (9.16.15-r0) 3.363 (22/35) Installing ca-certificates (-r4) 3.426 (23/35) Installing nghttp2-libs (1.41.0-r0) 3.456 (24/35) Installing libcurl (7.76.1-r0) 3.510 (25/35) Installing curl (7.76.1-r0) 3.561 (26/35) Installing iperf (2.0.13-r2) 3.607 (27/35) Installing libbz2 (1.0.8-r1) 3.649 (28/35) Installing fts (1.2.7-r1) 3.691 (29/35) Installing libelf (0.179-r0) 3.774 (30/35) Installing libmnl (1.0.4-r0) 3.814 (31/35) Installing libnftnl-libs (1.1.6-r0) 3.865 (32/35) Installing iptables (1.8.4-r2) 4.387 (33/35) Installing iproute2 (5.6.0-r0) 4.535 Executing iproute2-5.6.0- 4.540 ERROR: iproute2-5.6.0- script exited with error 1 4.540 (34/35) Installing libbsd (0.10.0-r0) 4.584 (35/35) Installing netcat-openbsd (1.130-r1) 4.627 Executing busybox-1.31.1-r20.trigger 4.632 ERROR: busybox-1.31.1-r20.trigger: script exited with error 1 4.632 Executing ca-certificates--r4.trigger 4.686 2 errors; 29 MiB in 49 packages ERROR: executor failed running [/dev/.buildkitqemuemulator /bin/sh -c apk --update add bind-tools curl netcat-openbsd iproute2 iperf bash && rm -rf /var/cache/apk/ && ln -s /usr/bin/iperf /usr/local/bin/iperf && ls -altrh /usr/local/bin/iperf]: exit code: 2 failed to solve: rpc error: code = Unknown desc = executor failed running [/dev/.buildkitqemu_emulator /bin/sh -c apk --update add bind-tools curl netcat-openbsd iproute2 iperf bash && rm -rf /var/cache/apk/ && ln -s /usr/bin/iperf /usr/local/bin/iperf && ls -altrh /usr/local/bin/iperf]: exit code: 2 make: ** [Makefile:43: all-build-and-push] Error 1 ERROR ERROR: build step 0 "" failed: step exited with non-zero status: 2 ERROR: () build -78ae-4086-bc26- completed with status "FAILURE"
2021/04/30 16:58:31 Failed to run some build jobs: [error running [gcloud builds submit --verbosity info --config --substitutions PULLBASEREF=master,WHAT=agnhost,GITTAG=v20210430-v1.22.0-alpha.1-58-gf039f94a6fe --project k8s-staging-e2e-test-images --gcs-log-dir gs://k8s-staging-e2e-test-images-gcb/logs --gcs-source-staging-dir gs://k8s-staging-e2e-test-images-gcb/source gs://k8s-staging-e2e-test-images-gcb/source/-1c8a-4141-9bbb-]: exit status 1] Need this fixed to finish image version dance to fix conformance tests for 1.21.1:
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
This has failed 3 times consecutively now. All because s390x issues ... I've manually re-triggered it the fourth time. /sig testing but also /sig release because this is a major problem for continuing to ship this platform. cc We've seen this before with flakes across other image builds for this platform.
looks like the latest run passed -
there's still underlying flakiness i need to get to the bottom of
Also what latest run? Were new changes made without bumping the version? Or did someone else manually trigger it yet again?
I just saw a green run at and the image was pullable, so I thought it had succeeded
I think someone must have retried it again manually. Postsubmits only run on merge, and we've had nothing else merge
Guirish tried to see whether our local s390x environment has the same problem too, he'll update us here.
the issue seams to be intermittent caused while pulling respective binaries from Alpine repo. I tried to reproduce the issue locally, I am observing similar build failures while cross building the image for other ARCH too, so the issue is not specific to s390x and it is to do with alpine repo.
thanks i've filed a PR that may help mitigate please review!
looks like a long pending problem
Interesting. FWIW 4/4 consecutive failures appeared to be s390x in CI. We've had previous flakes relating to symlinks affecting this platform only.

# - iproute2: includes ss used in NodePort tests # from iperf image # install necessary packages: iperf, bash <del> RUN apk --update add bind-tools curl netcat-openbsd iproute2 iperf bash && rm -rf /var/cache/apk/*  </del> <ins> RUN retry () { i=0; while [ $i -lt 9 ]; do "$@" && return || sleep 30; i="${i+1}"; done; "$@"; }  && retry apk --update add bind-tools curl netcat-openbsd iproute2 iperf bash && rm -rf /var/cache/apk/*  </ins> && ln -s /usr/bin/iperf /usr/local/bin/iperf  && ls -altrh /usr/local/bin/iperf


Question:
kubelet increased more than 100MB in memory in 4 days. kubelet to not used that amount of RAM I have reproduced it using 3 cronjobs which create hello world pods each minute and another cronjob that writes a line to a file each minute. Kubernetes version (use ): v1.18.1 Cloud provider or hardware configuration happens on both virtualbox and baremetal OS (e.g: ): centos 7 Kernel (e.g. ): 18.0-147.3.1 I have seen some existing issues like but I do not have any dangling resources associated with the cgroup.
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 node
/assign This is a duplicate issue, there has been a fixed PR but it has not been merged.

} if err = watcher.AddWatch(path, inotify.InOpen|inotify.InDeleteSelf); err != nil { klog.ErrorS(err, "Unable to watch lockfile") <ins> watcher.Close() </ins> return err } go func() {


Question:
kubelet increased more than 100MB in memory in 4 days. kubelet to not used that amount of RAM I have reproduced it using 3 cronjobs which create hello world pods each minute and another cronjob that writes a line to a file each minute. Kubernetes version (use ): v1.18.1 Cloud provider or hardware configuration happens on both virtualbox and baremetal OS (e.g: ): centos 7 Kernel (e.g. ): 18.0-147.3.1 I have seen some existing issues like but I do not have any dangling resources associated with the cgroup.
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 node
/assign This is a duplicate issue, there has been a fixed PR but it has not been merged.

klog.ErrorS(err, "inotify watcher error") } close(done) <ins> watcher.Close() </ins> }() return nil }


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.

v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" storagev1 "k8s.io/api/storage/v1" <del> storagev1beta1 "k8s.io/api/storage/v1beta1" </del> apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema"


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.

}, } <del> var betaTest *testsuites.StorageClassTest </del> for i, t := range tests { // Beware of closure, use local variables instead of those from // outer scope


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.

continue } <del> // Remember the last supported test for subsequent test of beta API betaTest = &test </del> ginkgo.By("Testing " + test.Name) suffix := fmt.Sprintf("%d", i) test.Client = c


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.

test.TestDynamicProvisioning() } <del> // Run the last test with storage.k8s.io/v1beta1 on pvc if betaTest != nil { ginkgo.By("Testing " + betaTest.Name + " with beta volume provisioning") betaClass := newBetaStorageClass(*betaTest, "beta") // create beta class manually betaClass, err := c.StorageV1beta1().StorageClasses().Create(context.TODO(), betaClass, metav1.CreateOptions{}) framework.ExpectNoError(err) defer deleteStorageClass(c, betaClass.Name) // fetch V1beta1 StorageClass as V1 object for the test class, err := c.StorageV1().StorageClasses().Get(context.TODO(), betaClass.Name, metav1.GetOptions{}) framework.ExpectNoError(err) betaTest.Client = c betaTest.Class = class betaTest.Claim = e2epv.MakePersistentVolumeClaim(e2epv.PersistentVolumeClaimConfig{ ClaimSize:        betaTest.ClaimSize, StorageClassName: &class.Name, VolumeMode:       &betaTest.VolumeMode, }, ns) betaTest.Claim.Spec.StorageClassName = &(class.Name) (*betaTest).TestDynamicProvisioning() } </del> }) ginkgo.It("should provision storage with non-default reclaim policy Retain", func() {


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.

} } <del> // TODO: remove when storage.k8s.io/v1beta1 is removed. func newBetaStorageClass(t testsuites.StorageClassTest, suffix string) *storagev1beta1.StorageClass { pluginName := t.Provisioner if pluginName == "" { pluginName = getDefaultPluginName() } if suffix == "" { suffix = "default" } return &storagev1beta1.StorageClass{ TypeMeta: metav1.TypeMeta{ Kind: "StorageClass", }, ObjectMeta: metav1.ObjectMeta{ GenerateName: suffix + "-", }, Provisioner: pluginName, Parameters:  t.Parameters, } } </del> func startGlusterDpServerPod(c clientset.Interface, ns string) *v1.Pod { podClient := c.CoreV1().Pods(ns)


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

# etcd - name: "etcd" <del> version: 3.5.0-rc.0 </del> <ins> version: 3.5.0 </ins> refPaths: - path: cluster/gce/manifests/etcd.manifest match: etcd_docker_tag|etcd_version


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

NUM_ADDITIONAL_NODES=${NUM_ADDITIONAL_NODES:-} ADDITIONAL_MACHINE_TYPE=${ADDITIONAL_MACHINE_TYPE:-} <del> # Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. v3.5.0-rc.0-0) if you need </del> <ins> # Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. v3.5.0-0) if you need </ins> # non-default version. export ETCD_IMAGE=${TEST_ETCD_IMAGE:-} export ETCD_DOCKER_REPOSITORY=${TEST_ETCD_DOCKER_REPOSITORY:-}


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

export SECONDARY_RANGE_NAME="pods-default" export STORAGE_BACKEND="etcd3" export STORAGE_MEDIA_TYPE="application/vnd.kubernetes.protobuf" <del> export ETCD_IMAGE=3.5.0-rc.0-0 export ETCD_VERSION=3.5.0-rc.0 </del> <ins> export ETCD_IMAGE=3.5.0-0 export ETCD_VERSION=3.5.0 </ins> # Upgrade master with updated kube envs "${KUBE_ROOT}/cluster/gce/upgrade.sh" -M -l


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

MinExternalEtcdVersion = "3.2.18" // DefaultEtcdVersion indicates the default etcd version that kubeadm uses <del> DefaultEtcdVersion = "3.5.0-rc.0-0" </del> <ins> DefaultEtcdVersion = "3.5.0-0" </ins> // Etcd defines variable used internally when referring to etcd component Etcd = "etcd"


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

19: "3.4.13-0", 20: "3.4.13-0", 21: "3.4.13-0", <del> 22: "3.5.0-rc.0-0", 23: "3.5.0-rc.0-0", </del> <ins> 22: "3.5.0-0", 23: "3.5.0-0", </ins> } // KubeadmCertsClusterRoleName sets the name for the ClusterRole that allows


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

# A set of helpers for starting/running etcd for tests <del> ETCD_VERSION=${ETCD_VERSION:-3.5.0-rc.0} </del> <ins> ETCD_VERSION=${ETCD_VERSION:-3.5.0} </ins> ETCD_HOST=${ETCD_HOST:-127.0.0.1} ETCD_PORT=${ETCD_PORT:-2379} export KUBE_INTEGRATION_ETCD_URL="http://${ETCD_HOST}:${ETCD_PORT}"


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

imagePullPolicy: Never args: [ "--etcd-servers=http://localhost:2379" ] - name: etcd <del> image: quay.io/coreos/etcd:v3.5.0-rc.0 </del> <ins> image: quay.io/coreos/etcd:v3.5.0 </ins>


Question:
/sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: Instructions 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.

e2essh "k8s.io/kubernetes/test/e2e/framework/ssh" ) <del> const etcdImage = "3.5.0-rc.0-0" </del> <ins> const etcdImage = "3.5.0-0" </ins> // EtcdUpgrade upgrades etcd on GCE. func EtcdUpgrade(targetStorage, targetVersion string) error {


Question:
Creating a service with fails to be created when trying to use a TCP health probe. Example service: Failed as follows: Health probe works correctly and is registered properly as TCP health probe. Take the mentioned service yaml and apply it, together with a corresponding pod / deployment exposing port 445. E.g. like this: The respective code seems to take the wrong path to me (it's +/- the same code on the in-tree as on the out of tree cloud provider): My reading of the code and passed values are like this: returns returns -- because returns returns therefore: So the requestPath is not at this point and the azure API server returns a 400 bad request. Kubernetes version (use ): 1.20.6 Cloud provider or hardware configuration: azure OS (e.g: ): linux Network plugin and version (if this is a network-related bug): vxlan & flannel
/sig cloud-provider
related PR introducing the feature:
/assign /triage accepted
/assign

# See the License for the specific language governing permissions and # limitations under the License. <del> # Set provider independent environment variables </del> <ins> # Set the default provider of Kubernetes cluster to know where to load provider-specific scripts # You can override the default provider by exporting the KUBERNETES_PROVIDER # variable in your bashrc # # The valid values: 'gce', 'azure' and 'vagrant' </ins> <del> # Set provider of Kubernetes cluster to know where to load provider-specific scripts, values: gce, vagrant, etc. KUBERNETES_PROVIDER="gce" #KUBERNETES_PROVIDER="vagrant" </del> <ins> KUBERNETES_PROVIDER=${KUBERNETES_PROVIDER:-gce} </ins>


Question:
When we introduced we an additional check during attach disk call to check for canonical path - Now this is creating a regression in many deployments because when volume is created, canonical path gets replaced - and hence when attach is attempted k8s can't find canonical path of the volume anymore. It throws following error: There are two ways of fixing this. We could decide to use old in attach code, if we can't fetch canonical path or we could decide not to replace canonical path during provisioning. cc /sig storage
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
cc:
The code that replaces canonical Path during provisioning is pretty old and hence I don't remember/know why we are doing that. But since there could be many existing PVs that now have different canonical path - I think it might be safest to merge - to prevent any regressions.

return "", err } <del> // try and get canonical path for disk and if we can't throw error vmDiskPath, err = getcanonicalVolumePath(ctx, vm.Datacenter, vmDiskPath) if err != nil { klog.Errorf("failed to get canonical path for %s on node %s: %v", vmDiskPath, convertToString(nodeName), err) return "", err </del> <ins> // try and get canonical path for disk and if we can't use provided vmDiskPath canonicalPath, pathFetchErr := getcanonicalVolumePath(ctx, vm.Datacenter, vmDiskPath) if canonicalPath != "" && pathFetchErr == nil { vmDiskPath = canonicalPath </ins> } diskUUID, err = vm.AttachDisk(ctx, vmDiskPath, &vclib.VolumeOptions{SCSIControllerType: vclib.PVSCSIControllerType, StoragePolicyName: storagePolicyName})


Question:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://prow.ppc64le- Below two test cases started failing on ppc64le: 6th June 2021 https://k8s- ... was the delta between the passing and failing tests Started failing after
/assign
/sig cloud-provider /priority important-soon /triage accepted /assign
Thanks for reporting the issue. This was caused by vendor changes in , which introduced external dependency on IMDS. If IMDS endpoint is not reachable, then the new logic would report error.
Filed to clean up the failed tests.

} ) <del> func TestGetServicePrincipalTokenFromMSIWithUserAssignedID(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSIWithUserAssignedID(msiEndpoint, env.ServiceManagementEndpoint, config.UserAssignedIdentityID) assert.NoError(t, err) assert.Equal(t, token, spt) } } func TestGetServicePrincipalTokenFromMSI(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSI(msiEndpoint, env.ServiceManagementEndpoint) assert.NoError(t, err) assert.Equal(t, token, spt) } } </del> func TestGetServicePrincipalToken(t *testing.T) { config := &AzureAuthConfig{ TenantID:        "TenantID",


Question:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

} func (q *graceTerminateRSList) flushList(handler func(rsToDelete *listItem) (bool, error)) bool { <ins> q.lock.Lock() defer q.lock.Unlock() </ins> success := true for name, rs := range q.list { deleted, err := handler(rs)


Question:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

} if deleted { klog.InfoS("Removed real server from graceful delete real server list", "realServer", name) <del> q.remove(rs) </del> <ins> delete(q.list, rs.String()) </ins> } } return success


Question:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

package ipvs import ( <ins> "fmt" netutils "k8s.io/utils/net" </ins> "reflect" "testing" utilipvs "k8s.io/kubernetes/pkg/util/ipvs" utilipvstest "k8s.io/kubernetes/pkg/util/ipvs/testing" <del> netutils "k8s.io/utils/net" </del> ) func Test_GracefulDeleteRS(t *testing.T) {


Question:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)

}) } } <ins> func Test_RaceTerminateRSList(t *testing.T) { ipvs := &utilipvstest.FakeIPVS{} gracefulTerminationManager := NewGracefulTerminationManager(ipvs) go func() { for i := 1; i <= 10; i++ { for j := 1; i <= 100; j++ { gracefulTerminationManager.rsList.add(makeListItem(i, j)) } } }() if !gracefulTerminationManager.rsList.flushList(gracefulTerminationManager.deleteRsFunc) { t.Error("failed to flush entries") } } func makeListItem(i, j int) *listItem { vs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, i) rs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, j) return &listItem{ VirtualServer: &utilipvs.VirtualServer{ Address:  netutils.ParseIPSloppy(vs), Protocol: "tcp", Port:     uint16(80), }, RealServer: &utilipvs.RealServer{ Address: netutils.ParseIPSloppy(rs), Port:    uint16(80), }, } } </ins>


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

case *corev1.Pod: // if allContainers is true, then we're going to locate all containers and then iterate through them. At that point, "allContainers" is false if !allContainers { <ins> currOpts := new(corev1.PodLogOptions) if opts != nil { opts.DeepCopyInto(currOpts) } </ins> // in case the "kubectl.kubernetes.io/default-container" annotation is present, we preset the opts.Containers to default to selected // container. This gives users ability to preselect the most interesting container in pod. <del> if annotations := t.GetAnnotations(); annotations != nil && len(opts.Container) == 0 { var containerName string </del> <ins> if annotations := t.GetAnnotations(); annotations != nil && currOpts.Container == "" { var defaultContainer string </ins> if len(annotations[podcmd.DefaultContainerAnnotationName]) > 0 { <del> containerName = annotations[podcmd.DefaultContainerAnnotationName] </del> <ins> defaultContainer = annotations[podcmd.DefaultContainerAnnotationName] </ins> } else if len(annotations[defaultLogsContainerAnnotationName]) > 0 { // Only log deprecation if we have only the old annotation. This allows users to // set both to support multiple versions of kubectl; if they are setting both // they must already know it is deprecated, so we don't need to add noisy // warnings. <del> containerName = annotations[defaultLogsContainerAnnotationName] </del> <ins> defaultContainer = annotations[defaultLogsContainerAnnotationName] </ins> fmt.Fprintf(os.Stderr, "Using deprecated annotation `kubectl.kubernetes.io/default-logs-container` in pod/%v. Please use `kubectl.kubernetes.io/default-container` insteadn", t.Name) } <del> if len(containerName) > 0 { if exists, _ := podcmd.FindContainerByName(t, containerName); exists != nil { opts.Container = containerName </del> <ins> if len(defaultContainer) > 0 { if exists, _ := podcmd.FindContainerByName(t, defaultContainer); exists == nil { fmt.Fprintf(os.Stderr, "Default container name %q not found in pod %sn", defaultContainer, t.Name) </ins> } else { <del> fmt.Fprintf(os.Stderr, "Default container name %q not found in a podn", containerName) </del> <ins> currOpts.Container = defaultContainer </ins> } } } <del> var containerName string if opts == nil || len(opts.Container) == 0 { </del> <ins> if currOpts.Container == "" { </ins> // We don't know container name. In this case we expect only one container to be present in the pod (ignoring InitContainers). // If there is more than one container, we should return an error showing all container names. if len(t.Spec.Containers) != 1 {


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

return nil, errors.New(err) } <del> containerName = t.Spec.Containers[0].Name } else { containerName = opts.Container </del> <ins> currOpts.Container = t.Spec.Containers[0].Name </ins> } <del> container, fieldPath := podcmd.FindContainerByName(t, containerName) </del> <ins> container, fieldPath := podcmd.FindContainerByName(t, currOpts.Container) </ins> if container == nil { <del> return nil, fmt.Errorf("container %s is not valid for pod %s", opts.Container, t.Name) </del> <ins> return nil, fmt.Errorf("container %s is not valid for pod %s", currOpts.Container, t.Name) </ins> } ref, err := reference.GetPartialReference(scheme.Scheme, t, fieldPath) if err != nil {


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

} ret := make(map[corev1.ObjectReference]rest.ResponseWrapper, 1) <del> ret[*ref] = clientset.Pods(t.Namespace).GetLogs(t.Name, opts) </del> <ins> ret[*ref] = clientset.Pods(t.Namespace).GetLogs(t.Name, currOpts) </ins> return ret, nil }


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

name: "pod logs", obj:  testPodWithOneContainers(), actions: []testclient.Action{ <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{ {


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

Items: []corev1.Pod{*testPodWithOneContainers()}, }, actions: []testclient.Action{ <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{{ Kind:       testPodWithOneContainers().Kind,


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

}}, }, { <ins> name: "pods list logs: default container should not leak across pods", obj: &corev1.PodList{ Items: []corev1.Pod{ { TypeMeta: metav1.TypeMeta{ Kind:       "pod", APIVersion: "v1", }, ObjectMeta: metav1.ObjectMeta{ Name:      "foo", Namespace: "test", Labels:    map[string]string{"test": "logs"}, Annotations: map[string]string{ "kubectl.kubernetes.io/default-container": "c1", }, }, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyAlways, DNSPolicy:     corev1.DNSClusterFirst, Containers: []corev1.Container{ {Name: "c1"}, {Name: "c2"}, }, }, }, { TypeMeta: metav1.TypeMeta{ Kind:       "pod", APIVersion: "v1", }, ObjectMeta: metav1.ObjectMeta{ Name:      "bar", Namespace: "test", Labels:    map[string]string{"test": "logs"}, }, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyAlways, DNSPolicy:     corev1.DNSClusterFirst, Containers: []corev1.Container{ {Name: "c2"}, }, }, }, }, }, actions: []testclient.Action{ getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), getLogsAction("test", &corev1.PodLogOptions{Container: "c2"}), }, expectedSources: []corev1.ObjectReference{{ Kind:       "pod", APIVersion: "v1", Name:       "foo", Namespace:  "test", FieldPath:  fmt.Sprintf("spec.containers{%s}", "c1"), }, { Kind:       "pod", APIVersion: "v1", Name:       "bar", Namespace:  "test", FieldPath:  fmt.Sprintf("spec.containers{%s}", "c2"), }}, }, { </ins> name: "pods list logs: all containers", obj: &corev1.PodList{ Items: []corev1.Pod{*testPodWithTwoContainersAndTwoInitContainers()},


Question:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close Instructions 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

clientsetPods: []runtime.Object{testPodWithOneContainers()}, actions: []testclient.Action{ testclient.NewListAction(podsResource, podsKind, "test", metav1.ListOptions{LabelSelector: "foo=bar"}), <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{{ Kind:       testPodWithOneContainers().Kind,


Question:
we have one in k/k and one in k/utils, both need to be in LICENSES /assign
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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?

<ins> Copyright ©2013 The gonum Authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the gonum project nor the names of its authors and contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. </ins>  No newline at end of file