Question: return false, nil })) <del> pod := &v1.Pod{ </del> <ins> zero := int64(0) pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(&v1.Pod{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> GenerateName: "pod-service-account-" + string(uuid.NewUUID()) + "-", </del> <ins> Name: "pod-service-account-" + string(uuid.NewUUID()), </ins> }, Spec: v1.PodSpec{ <del> Containers: []v1.Container{ { Name:  "token-test", Image: mountImage, Args: []string{ fmt.Sprintf("--file_content=%s/%s", serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountTokenKey), }, }, { Name:  "root-ca-test", Image: mountImage, Args: []string{ fmt.Sprintf("--file_content=%s/%s", serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountRootCAKey), }, }, }, RestartPolicy: v1.RestartPolicyNever, }, } pod.Spec.Containers = append(pod.Spec.Containers, v1.Container{ Name:  "namespace-test", Image: mountImage, Args: []string{ fmt.Sprintf("--file_content=%s/%s", serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountNamespaceKey), </del> <ins> ServiceAccountName: sa.Name, Containers: []v1.Container{{ Name:    "test", Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"sleep", "100000"}, // run and pause }}, TerminationGracePeriodSeconds: &zero,                 // terminate quickly when deleted RestartPolicy:                 v1.RestartPolicyNever, // never restart </ins> }, }) <ins> framework.ExpectNoError(err) framework.ExpectNoError(framework.WaitForPodRunningInNamespace(f.ClientSet, pod)) </ins> <del> f.TestContainerOutput("consume service account token", pod, 0, []string{ fmt.Sprintf(`content of file "%s/%s": %s`, serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountTokenKey, tokenContent), }) f.TestContainerOutput("consume service account root CA", pod, 1, []string{ fmt.Sprintf(`content of file "%s/%s": %s`, serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountRootCAKey, rootCAContent), }) </del> <ins> mountedToken, err := f.ReadFileViaContainer(pod.Name, pod.Spec.Containers[0].Name, path.Join(serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountTokenKey)) framework.ExpectNoError(err) mountedCA, err := f.ReadFileViaContainer(pod.Name, pod.Spec.Containers[0].Name, path.Join(serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountRootCAKey)) framework.ExpectNoError(err) mountedNamespace, err := f.ReadFileViaContainer(pod.Name, pod.Spec.Containers[0].Name, path.Join(serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountNamespaceKey)) framework.ExpectNoError(err) </ins> <del> f.TestContainerOutput("consume service account namespace", pod, 2, []string{ fmt.Sprintf(`content of file "%s/%s": %s`, serviceaccount.DefaultAPITokenMountPath, v1.ServiceAccountNamespaceKey, f.Namespace.Name), }) </del> <ins> // CA and namespace should be identical Expect(mountedCA).To(Equal(rootCAContent)) Expect(mountedNamespace).To(Equal(f.Namespace.Name)) // Token should be a valid credential that identifies the pod's service account tokenReview := &authenticationv1.TokenReview{Spec: authenticationv1.TokenReviewSpec{Token: mountedToken}} tokenReview, err = f.ClientSet.AuthenticationV1().TokenReviews().Create(tokenReview) framework.ExpectNoError(err) Expect(tokenReview.Status.Authenticated).To(Equal(true)) Expect(tokenReview.Status.Error).To(Equal("")) Expect(tokenReview.Status.User.Username).To(Equal("system:serviceaccount:" + f.Namespace.Name + ":" + sa.Name)) groups := sets.NewString(tokenReview.Status.User.Groups...) Expect(groups.Has("system:authenticated")).To(Equal(true), fmt.Sprintf("expected system:authenticated group, had %v", groups.List())) Expect(groups.Has("system:serviceaccounts")).To(Equal(true), fmt.Sprintf("expected system:serviceaccounts group, had %v", groups.List())) Expect(groups.Has("system:serviceaccounts:"+f.Namespace.Name)).To(Equal(true), fmt.Sprintf("expected system:serviceaccounts:"+f.Namespace.Name+" group, had %v", groups.List())) </ins> }) /*

https://k8s- /sig auth /kind failing-test
Adding a priority to this: /priority important-soon Please raise the priority if you consider this a release blocker. Given the test job, it normally wouldn't be.
It's a test issue. I'm hoping to fix this before 1.13 but I don't consider it a release blocker.


Question: } } } <ins> func TestGetPodStatusWithLastTermination(t *testing.T) { testKubelet := newTestKubelet(t) testKubelet.fakeCadvisor.On("MachineInfo").Return(&cadvisorApi.MachineInfo{}, nil) kubelet := testKubelet.kubelet fakeDocker := testKubelet.fakeDocker waitGroup := testKubelet.waitGroup containers := []api.Container{ {Name: "succeeded"}, {Name: "failed"}, } runningAPIContainers := []docker.APIContainers{ { // pod infra container Names: []string{"/k8s_POD_foo_new_12345678_0"}, ID:    "9876", }, } exitedAPIContainers := []docker.APIContainers{ { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_succeeded." + strconv.FormatUint(dockertools.HashContainer(&containers[0]), 16) + "_foo_new_12345678_0"}, ID:    "1234", }, { // format is // k8s_<container-id>_<pod-fullname>_<pod-uid> Names: []string{"/k8s_failed." + strconv.FormatUint(dockertools.HashContainer(&containers[1]), 16) + "_foo_new_12345678_0"}, ID:    "5678", }, } containerMap := map[string]*docker.Container{ "1234": { ID:     "1234", Name:   "succeeded", Config: &docker.Config{}, State: docker.State{ ExitCode:   0, StartedAt:  time.Now(), FinishedAt: time.Now(), }, }, "5678": { ID:     "5678", Name:   "failed", Config: &docker.Config{}, State: docker.State{ ExitCode:   42, StartedAt:  time.Now(), FinishedAt: time.Now(), }, }, } tests := []struct { policy           api.RestartPolicy created          []string stopped          []string lastTerminations []string }{ { api.RestartPolicyAlways, []string{"succeeded", "failed"}, []string{}, []string{"docker://1234", "docker://5678"}, }, { api.RestartPolicyOnFailure, []string{"failed"}, []string{}, []string{"docker://5678"}, }, { api.RestartPolicyNever, []string{}, []string{"9876"}, []string{}, }, } for i, tt := range tests { fakeDocker.ContainerList = runningAPIContainers fakeDocker.ExitedContainerList = exitedAPIContainers fakeDocker.ContainerMap = containerMap fakeDocker.ClearCalls() pods := []api.Pod{ { ObjectMeta: api.ObjectMeta{ UID:       "12345678", Name:      "foo", Namespace: "new", }, Spec: api.PodSpec{ Containers:    containers, RestartPolicy: tt.policy, }, }, } kubelet.podManager.SetPods(pods) waitGroup.Add(1) err := kubelet.SyncPods(pods, emptyPodUIDs, map[string]api.Pod{}, time.Now()) if err != nil { t.Errorf("%d: unexpected error: %v", i, err) } waitGroup.Wait() // Check if we can retrieve the pod status from GetPodStatus(). podName := kubecontainer.GetPodFullName(&pods[0]) status, err := kubelet.GetPodStatus(podName) if err != nil { t.Fatalf("unable to retrieve pod status for pod %q: %#v.", podName, err) } else { terminatedContainers := []string{} for _, cs := range status.ContainerStatuses { if cs.LastTerminationState.Termination != nil { terminatedContainers = append(terminatedContainers, cs.LastTerminationState.Termination.ContainerID) } } sort.StringSlice(terminatedContainers).Sort() sort.StringSlice(tt.lastTerminations).Sort() if !reflect.DeepEqual(terminatedContainers, tt.lastTerminations) { t.Errorf("Expected(sorted): %#v, Actual(sorted): %#v", tt.lastTerminations, terminatedContainers) } } if err := fakeDocker.AssertCreated(tt.created); err != nil { t.Errorf("%d: %v", i, err) } if err := fakeDocker.AssertStopped(tt.stopped); err != nil { t.Errorf("%d: %v", i, err) } } } </ins>

Currently kubelet reports current status only. If pod's restart policy is not never, the last terminated container status will be override by the latest status, and lost. We should report last terminated container status. I am going to update our v1beta3 api first, but will hold the implementation until we have
did you have a chance to start working on it? IIUC, to support this we need to change the api (), which IIUC from what wrote in some other thread should be done this week. I'm happy to help with it if you want me to help.
Only breaking changes have a deadline. Additive changes can be done at any time.
I am working on this. PR should be ready today or tomorrow.
Also agree with This is not part of API breakage.
Thanks for answers & clarifications and


Question: } for _, test := range testCases { <del> setTestVirtualMachineScaleSets(ss, test.scaleSet, test.vmList) </del> <ins> ss := newTestScaleSet(test.scaleSet, test.vmList) </ins> real, err := ss.GetInstanceIDByNodeName(test.nodeName) if test.expectError { assert.Error(t, err, test.description)

/kind bug What happened: https://k8s-
/sig azure
I find the root cause, and can fix it.
/kind bug
/cc
Cool, thanks


Question: match: const etcdImage - name: "docker" <del> version: 18.09 </del> <ins> version: 19.03 </ins> refPaths: - path: cmd/kubeadm/app/util/system/docker_validator.go match: latestValidatedDockerVersion

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Support for newer docker versions: 19.x Why is this needed: New users trying to use kubernetes install the latest docker version. It's inconvenient see the following warning and have to uninstall docker and then install an older version. Also, it's not clear what could happen if someone uses a newer version of docker. Lastly, I believe that kubernetes should be able to keep up with docker. Is there any roadmap for this, that I have missed?
/sig usability
you could work with sig-testing and sig-node to set up CI jobs when new versions of Docker shows up. Believe me, it's more inconvenient to debug failures in a new docker version as a end use than the downgrade. We have to have some CI coverage of a version before we ok its use by the community.
Hi I'm new to this, so I'm not sure how to apply your suggestion: Is there any documentation that I could use?
SIGs are teams working on specific areas of kubernetes All our test infrastructure for CI jobs ("Continuous Integration") is in: Out test-grid is here (please type docker in the search box on top to see the current CI jobs):
Since docker-ce 18.09 has reached EOL and there are no new versions planned (), it would be great to have official support for a newer version of docker-ce.
please see:
Hi folks, David from Docker here, we have run and validated Docker Engine 19.03 for Kubernetes 1.14 back in June, so Docker 19.03 is indeed supported for Kubernetes 1.14 and above: Let me know how else we can help.
thanks for confirming PR is here
Thank you Appreciate the PR, we typically test engines for major versions of Engine that are released like 19.03 with the latest version of Kubernetes that is available at the time. On our next engine, we will re-run the test and submit the results to testgrid. Let me know how I can better coordinate this.
Also let me know if there is anything else that is needed to close this issue out. Thanks.
hi, the PR should close this issue. i guess, one option is just creating a similar issue once the test job is available in test-grid and running green for a while? or me can then proceed to update the validators.

Ok thank you, that sounds like a good process we can follow moving forward.
Hi Any chance this can make its way into 1.16 at least? This way it may get picker up by Kops and not have to rely on some old and unpatched Docker version. At the moment Docker CE 18.09 is no longer actively supported
hi, we cannot backport this as it's not a critical fix. at least in the case of kubeadm the 19. versions of docker would only print a warning.
but doesn't the existence of a vulnerability make this critical enough?
the usage of Docker 19. is not blocked in any way in 1.16. you can ignore the and just use it. if something was blocking the usage of 19., then this is backport worthy.
I saw this as the first step before adding 19.03 as a validated external release. Without being documented as such Kops will not pick it up as default and will leave people with old and vulnerable Docker versions. If this I understand correctly the above comments, 19.03 has been validated for some time, just not documented.
i don't think kops uses the kubeadm validators that reside in k/k/cmd/kubeadm/app/... this was resolved in this PR the k8s docs for CRI are still out of date: so if someone wants to send a PR for that page please go ahead: (but AFAIK not all distros have moved to 19. yet)
I couldn't find any repos missing docker 19.03.4. Any chance to do the change in the changelog?


Question: endif ALL_K8S_TAG_FILES := $(shell                              find $(ALL_GO_DIRS) -maxdepth 1 -type f -name *.go   <del> | xargs grep -l '^// *+k8s:'                      </del> <ins> | xargs grep --color=never -l '^// *+k8s:'        </ins> ) #

Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)


Question: // This test verifies we don't allow scheduling of pods in a way that sum of local ephemeral storage limits of pods is greater than machines capacity. // It assumes that cluster add-on pods stay stable and cannot be run in parallel with any other test that touches Nodes or Pods. // It is so because we need to have precise control on what's running in the cluster. <del> It("validates local ephemeral storage resource limits of pods that are allowed to run [Conformance]", func() { </del> <ins> It("validates local ephemeral storage resource limits of pods that are allowed to run [Feature:LocalStorageCapacityIsolation]", func() { </ins> nodeMaxAllocatable := int64(0) nodeToAllocatableMap := make(map[string]int64)

Is this a BUG REPORT or FEATURE REQUEST?: What happened: There are several CI e2e jobs that are failing this new Conformance test: [sig-scheduling] SchedulerPredicates [Serial] validates local ephemeral storage resource limits of pods that are allowed to run [Conformance] 1m6s Expected <bool: false to equal <bool: true Here is one such failure: https://k8s- Moreover, this new test has been consistently failing on multiple e2e jobs ever since it was merged to master: https://k8s- https://k8s- https://k8s- https://k8s- Here is the pull request for the new test: I don't know if this is a legitimate problem with the scheduler in these jobs and if the test is running and passing elsewhere, or if there is a flaw in the test itself.
CC to comment on the correctness of this new test, since it is failing both for kubeadm e2es and kops as well: https://k8s- I haven't been able to find any other e2e jobs where this test isn't skipped, so I don't know if it's green anywhere.
Also failing gce-serial and gke-serial: https://k8s- https://k8s-
Updated title/description since this isn't a kubeadm-specific CI failure.
Sorry for that, I will look into it /assign
LocalEphemeralStorage will be to node Status's capacity when feature gate is enabled. In e2e tests ,the feature gate is not enabled, so the error happened.
Thanks for looking into this, I'll be out of the office for the next few days (back on September 5th), so I would include more people on that PR so it's not stalled on my feedback. My personal vote is to change the test's tag from "[Conformance]" to "[Feature:EphemeralStorage]" so that test jobs will have to opt into running the test, but I don't know if we already have the pattern elsewhere of checking for whether or not a feature is enabled and skipping an enabled test anyway. SIG Testing might have guidelines for best practices here.

Sorry for not understanding the tag's meaning
/kind e2e-test-failure cc
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/cluster-lifecycle sig/scheduling: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
from what I can see this test has never passed for certain test suites. e.g. https://k8s- Would it be appropriate to revert the test?
See ; which fixes the main problem. I just asked to bump the priority


Question: "net" "net/http" "os" <ins> "reflect" </ins> "regexp" "strings" "time"

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I use but my cloud provider doesn't support Openstack LBaaS. Because of the latter I've been using MetalLB instead to get things going. However I keep getting warnings when deploying a when there is no configuration defined in . NOTE: has only a section - there is no mention no section. What you expected to happen: should not print warning via Openstack LoadBalancer since it doesn't support/can't do anything with it. How to reproduce it (as minimally and precisely as possible): Configure Push a Create a Anything else we need to know?: See this Environment: See this
/sig cloud-provider
/sig openstack
that error is coming from row but I am not 100% sure should we support metallb in openstack cloud provider integration. Metallb is not part of openstack. any opinion? anyways it is little bit weird that EnsureLoadBalancer function is even working if LoadBalancer section is not defined in config. Openstack lbaas is not initialized but that function is called?
if there is no LBaaS in the environment and or no , we should not try to deploy one (and let metallb to do the work as it is supposed to). i think.
when you start node, do you see this log print in logs? Can you try to add following to does creating service with type loadbalancer (with metallb) work after that without error prints?
~ With the original config doesnt show up in the log files. The only reference for in the logs is:~ UPDATE BELOW Now, if adding as it yields: And: The IP allocation via MetalLB works The service is remotely available The warning on object disappears:
weird, without this Loadbalancer thing in config it should end up to row and print "Claiming to support LoadBalancer". Now when you that Loadbalancer section with random lb-version it ends up to row and it does not have support to external loadbalancer from openstack. When using metallb the init function in openstack should return false (no support from openstack) but I do not have now idea why it does not do that (when you do not have that loadbalancer section in config)
I take it back. my log level was too high ().

After moving to it shows up when there is no section in :
cool, then we should have check in function as first thing which checks is LoadBalancer even defined in config - if no then return nil, false
(or someone else openstack guy) do you have time to run some test to fix this? I am on vacation and I do not have my test environment with me :) I am thinking to add following to row So I am trying to check is lbOpts totally empty, if yes - then it does not initialize openstack lbaas at all. Maybe I will do PR, but I do not have possibility to test it


Question: REGISTRY ?= gcr.io/kubernetes-e2e-test-images GOARM=7 QEMUVERSION=v2.9.1 <del> GOLANG_VERSION=1.11.1 </del> <ins> GOLANG_VERSION=1.11.2 </ins> export ifndef WHAT

go 1.11.2 is out 11/2 and this bug tracks upgrade to the latest version. Is it something we should absolutely needed in the 1.13 timeframe? are there any that should absolutely take? how long does the associated image updates and push take? If we chose to upgrade in 1.13, we should do it before code slush targeted for Friday 11/6. /assign can you please clarify the above ques and and help evaluate timing of the upgrade. /cc /sig release /sig testing /priority important-soon /kind cleanup
/cc I’ve already got a branch cooking for this, but waiting for rules_go support first. I think said in Slack that this will happen this week.
Ahh so is the earliest expected timeframe when we can upgrade falls into Code slush period for 1.13 (post 11/9?) Depending on when it lands we might want to see if its safe to wait for 1.13.1. are you aware of any critical fixes that make this compelling for 1.13 timeframe?
The risk for patch golang point releases is typically low (the minor releases, like 1.10 -1.11, are higher risk). I don't see anything that's critical or of known impact, but at the same time, I see compiler fixes and go/types package fixes. They are more subtle and could present issues later. I'd suggest that if we can tolerate getting it in, even if we're in slush, we should.
Ack that :) Plz ping this bug as soon as we are ready to build and push the upgraded images. we'll will make a final call depending on the timeframe and CI signal going in. thanks!


Question: allErrs = append(allErrs, field.Invalid(fldPath.Child("nodeName"), *address.NodeName, msg)) } } <del> allErrs = append(allErrs, validateEpAddrNodeNameTransition(address, ipToNodeName, fldPath.Child("nodeName"))...) if len(allErrs) > 0 { return allErrs } </del> allErrs = append(allErrs, validateNonSpecialIP(address.IP, fldPath.Child("ip"))...) return allErrs }

/kind bug What happened: We have noticed that one of the node-exporters is down. It turned out that service has "old" endpoint still. After digging deeper i see following errors in controller manager Turns out controller manager can not update endpoints for node-exporter service, because of this error. In endpoint list is see right IPs for worker nodes, but wrong IP for master node (that's why we detected the problem). Context: two worker nodes were recreated with new hostnames (generated randomly), but they use same ip address one master node were recreated with new hostname and new ip I've tried to manually update hostname and got same error, seems nodeName is not updatable field. It also affects all other endpoints, we were forced to recreated all pods (so they will change IPs) to be able to fix endpoints reconciliation. What you expected to happen: controller manager successfully update endpoints after node recreated with same IP, but different hostname. How to reproduce it (as minimally and precisely as possible): 1 master, 1 worker, service that points to pods with host network. k8s API service (keep it shut down) worker node with same IP and different host name to recreate pod on worker and in controller manager should appear error above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): CoreOS 1688.5.3 Kernel (e.g. ): 4.14.32-coreos Install tools: own tool () Others:
/sig node
what is the use case of changing node name?
/sig api-machinery
We have ephemeral immutable nodes in our clusters. So upgrade or any other operation will cause node recreation. Hostname generated automatically, but the IP address depends on the underlay hypervisor node, where node will be scheduled. So it's possible that node stays on the same hypervisor and uses same ip address.
/cc
/assign
/cc do you think it's reasonable to loose endpoints validation?
/sig network this API is owned by sig network


Question: }, }, } <del> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s)", nodeResourceGroup, vmName, diskName) </del> <ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s, %s)", nodeResourceGroup, vmName, diskName, diskURI) </ins> ctx, cancel := getContextWithCancel() defer cancel()

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: add more logging in azure disk attach/detach What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
The issue message here doesn't say why a change was desired. The PR "Original logging is not clear when dealing with managed disk, since diskName is empty". That's more informative.


Question: return false, pod, fmt.Errorf("invalid pod: %#v", obj) } <ins> if newPod.Name == "" { return true, pod, fmt.Errorf("invalid pod: name is needed for the pod") } </ins> // Apply default values and validate the pod. if err = defaultFn(newPod); err != nil { return true, pod, err

When I put a Pod yaml file without in , started the kubelet and hoped it would create the corresponding staticPod for me, I got the following error, which also caused the staticPod to not be created. I then read the kubelet code and quickly found the problem. When kubelet tries to decode the pod yaml file, it will apply default values and validate the pod. The function to apply the defaults is in . In this function, the is set. This causes an error when is not set, because it causes the '-' character to be at the front. I think kubelet should circumvent this error, because is optional, It is possible for this field not to be set. When Pod's is not set, the '-' character at the start should be avoided, as it will cause an error. Prepare a Pod yaml file without and set it into . If the maintainers think this circumvention change is necessary, I'm happy to contribute code to the kubelet! <details</details<details</details<detailsconsole $ cat /etc/os-release NAME="Alibaba Cloud Linux" VERSION="3 (Soaring Falcon)" ID="alinux" IDLIKE="rhel fedora centos anolis" VERSIONID="3" PLATFORMID="platform:al8" PRETTYNAME="Alibaba Cloud Linux 3 (Soaring Falcon)" ANSICOLOR="0;31" HOMEURL="" $ uname -a Linux cloud 5.10.134-14.al8.x8664 SMP Thu Apr 27 16:46:29 CST 2023 x8664 x8664 x8664 GNU/Linux </details<detailsusing kubeadm </details<details</details<details</details
/sig node
I would like to open a PR to fix this issue, can I be assigned?
If the maintainer thinks this should be fixed, I want it fixed by myself:)
OK
I do not know if a pod without name should be considered valid Please discuss with sig-node before doing anything to understand what is a valid solution for this problem /cc
names are needed for the Pod. I think the correct fix for this issue will be to add validation for static Pods to have a name. This validation is OK to add since Pods without names are not working anyways because of this bug.
Okay, I will submit a PR to add validation for static Pods to have a name.

Hey, I found out that kubelet will apply default value first and then validate the pod. Do you mean to let me add a single validation for static Pods to have a name before applying default value?
hi and If modified according to this logic, it seems that the current code is fine. Current logic: it will use the old pod.Name to generate the new pod.Name , in ValidatePodCreate, it will validate pod name. The pod.Name is already to new pod.Name this case, the original pod does not have a name and will also be recognized. It's just that it's identified with a validation prefixed with "-". The logic of the current validation will recognize the pod without a name. In this way, is it necessary to improve the error information?
/triage accepted
/priority backlog


Question: <ins> #!/usr/bin/env bash # Copyright 2014 The Kubernetes Authors All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. set -o errexit set -o nounset set -o pipefail pushd "../../../.." source "./hack/lib/util.sh" source "./hack/lib/logging.sh" source "./hack/lib/etcd.sh" popd cleanup() { kube::etcd::cleanup kube::log::status "performance test cleanup complete" } trap cleanup EXIT kube::etcd::start kube::log::status "performance test start" # TODO: set log-dir and prof output dir. DIR_BASENAME=$(basename `pwd`) go test -c -o "${DIR_BASENAME}.test" # We are using the benchmark suite to do profiling. Because it only runs a few pods and # theoretically it has less variance. "./${DIR_BASENAME}.test" -test.bench=. -test.run=xxxx -test.cpuprofile=prof.out -logtostderr=false kube::log::status "benchmark tests finished" # Running density tests. It might take a long time. "./${DIR_BASENAME}.test" -test.run=. -test.timeout=60m kube::log::status "density tests finished" </ins>

We have found that on 1k nodes cluster scheduling takes 60-200 ms and becomes the bottleneck. We want to have a standard way to reproduce scheduling latency metrics result and benchmark scheduler as simple and fast as possible. Only with that can we: 1. figure out underlying behaviors and potential bottlenecks quickly; 2. publish results in a standard way and prevent future performance degradation. We have the following goals: Goal 1: Save time on testing. More accurate scheduling latency. We mock up kubelets and only measure scheduling latency and do not care about the latency to start the pod. This is different from Kubemark -- scheduled pods won’t be run by mocked kubelets. We only need to set up the master components. Goal 2: Profiling runtime metrics and find out performance bottleneck. Write scheduler integration test. Take advantage of go test and profiling tools, like cpu-profiling, memory-profiling and block-profiling. This is very fine-grained metrics. Goal 3: Reproduce test result easily. We want to have a known place to do the performance related test for scheduler. Developers should just run one script to collect all the information they need. We have the following plans for writing scheduler tests: density test (by adding a new Go test) schedule 30k pods on 1000 (fake) nodes and 3k pods on 100 (fake) nodes print out scheduling rate every second let you learn the rate changes vs number of scheduled pods benchmark (by modifying the existing benchmark in integration or simply add a new one) make use of and report nanosecond/op. schedule b.N pods when the cluster has N nodes and P scheduled pods. Since it takes relatively long time to finish one round, b.N is small -- level of 10. We are new to k8s codebase. We also want to know where is the best place (directory) to commit in these tests? Any suggestions are welcomed!
/cc
This extends
So density already does this... the one option it looks like you may want is custom control , real or fake is irrelevant as the e2e's just need to point to an api-server. re: benchmarks, seems like we could simply add to the unit-tests.
After chatting with lets add this as an agenda item for the SIG meeting tomorrow.

+1 for adding benchmark (howeveer this should be integration test, not unit-test in my opinion)
cc The next SIG on scheduler meeting is on 12.07, isn't it? If there is one tomorrow, can I have the information please?
retract, +1 to . I was adding this to the list given the context, but it crosses over into both.
Slides from today's meeting:
Here are are the action item notes from the SIG meeting: Everyone agrees this is a good idea and long overdue, but the question is where would this live: New category of tests? (isolated/sandbox’d/component) The current testing structure allows to easily append. create new directory (component) + hack/script to execute Future "we could" gate on known good data, and fail performance regressions
/cc
/cc


Question: var ( // ClusterDefaults has the same behavior as the old EnvVar and DefaultCluster fields // DEPRECATED will be replaced <del> ClusterDefaults = clientcmdapi.Cluster{Server: os.Getenv("KUBERNETES_MASTER")} </del> <ins> ClusterDefaults = clientcmdapi.Cluster{Server: getDefaultServer()} </ins> // DefaultClientConfig represents the legacy behavior of this package for defaulting // DEPRECATED will be replace DefaultClientConfig = DirectClientConfig{*clientcmdapi.NewConfig(), "", &ConfigOverrides{

What happened: I am using a command like below in GitHub actions: I get the following error: What you expected to happen: Since I am using flag, it should work without requiring a valid kubeconfig file. How to reproduce it (as minimally and precisely as possible): Just delete your local kubeconfig file and try the above command. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
/assign /kind regression
This likely breaks some scripted usage of kubectl
This is related to /assign
Or
Yes, sorry I mentioned you in this issue. Because my first thought is this brings and which will check the config file existence but in fact that's not the root cause. Actually the root cause This checks config has the server or not. And with this , this function will return error when there's no local config file. I think there might be two solutions? the similar logic like to every , , ..... when or is set. Seems not a good idea. reverse this to have the default server which is better than ? By the way, is equals ? Since This works only for .
The plan I agreed on with Jordan is that I will revert since that seems to be the main culprit behind all these problems. I'll add a test ensuring this works as required. This will allow us to backport the fix to 1.18. For 1.19 I'll put together a proper fix supporting and flags.


Question: RestartPolicy: v1.RestartPolicyOnFailure, }, } <del> var volumeMounts = make([]v1.VolumeMount, len(pvclaims)) var volumes = make([]v1.Volume, len(pvclaims)) for index, pvclaim := range pvclaims { volumename := fmt.Sprintf("volume%v", index+1) volumeMounts[index] = v1.VolumeMount{Name: volumename, MountPath: "/mnt/" + volumename} volumes[index] = v1.Volume{Name: volumename, VolumeSource: v1.VolumeSource{PersistentVolumeClaim: &v1.PersistentVolumeClaimVolumeSource{ClaimName: pvclaim.Name, ReadOnly: false}}} } podSpec.Spec.Containers[0].VolumeMounts = volumeMounts podSpec.Spec.Volumes = volumes </del> <ins> setVolumes(&podSpec.Spec, pvclaims, nil /*inline volume sources*/, false /*PVCs readonly*/) </ins> if nodeSelector != nil { podSpec.Spec.NodeSelector = nodeSelector }

Apparently volumes with are incorrectly to : /sig storage /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


Question: // Option configures a PriorityQueue type Option func(*priorityQueueOptions) <del> // WithClock sets clock for PriorityQueue, the default clock is util.RealClock. func WithClock(clock util.Clock) Option { </del> <ins> // WithClock sets clock for PriorityQueue, the default clock is clock.RealClock. func WithClock(clock clock.Clock) Option { </ins> return func(o *priorityQueueOptions) { o.clock = clock }

We should use /kind cleanup
/remove-kind feature /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-kind feature /good-first-issue 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
/sig scheduling /triage accepted
/assign


Question: if !reflect.DeepEqual(expected, update) { t.Errorf("Expected: %#v, Got: %#v", expected, update) } <ins> for i := range update.Pods { if errs := kubelet.ValidatePod(&update.Pods[i]); len(errs) != 0 { t.Errorf("Expected no validation errors on %#v, Got %#v", update.Pods[i], errs) } } </ins> } func TestExtractFromHttpEmptyArray(t *testing.T) {

The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.


Question: return nil // Cause the goroutine to return } <ins> func (fake *fakeHTTPServer) Close() error { return nil } </ins> func mknsn(ns, name string) types.NamespacedName { return types.NamespacedName{ Namespace: ns,

When a LoadBalancer Service with Local ExternalTrafficPolicy was deleted normally, an error log "use of closed network connection" was always generated in kube-proxy log, which confused people that there was something wrong: Do not generate error log when it's expected. a LoadBalancer Service with Local ExternalTrafficPolicy it No response <detailsv1.26.0 </details<details</details<details</details<details</details<details</details<details</details
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 network


<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: With the exec credentials plugin configured in my kubeconf, and a stale/expired token present in the same file issuing e.g. triggers the authentication flow as handled by the plugin - once the flow is returned to kubectl (by printing the ExecCredential object) the new token is stored to the kubeconfig but not immediately used to resolve the request, leading to: Immediately issuing again works as kubectl now seem to use the credentials (token) stored following the first request. What you expected to happen: That kubectl would read the new token as fetched by the exec credential plugin and use it already for the first command issued. How to reproduce it (as minimally and precisely as possible): the kubernetes API server with the OIDC authenticator enabled. kubectl to use an exec credential plugin printing the token received out of band. that the token was indeed written to the kubeconf file. that the first kubectl command failed. that the next identical command succeeds. Anything else we need to know?: This works as expected when there is no token previously stored in the kubeconf - the behavior is only triggered when there is a token stored but it expired, or for whatever other reason not accepted by the API server. Environment: Kubernetes version (use ): 1.14, also tried with 1.17 Cloud provider or hardware configuration: OS (e.g: ): Mac OS for kubectl client Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig auth /sig cli
could you provide more details around how is configured. For example, it is unclear to me if you are using the built in oidc plugin or a custom exec plugin. I think you are using a custom exec plugin but its also trying to write tokens to the file (which it should not do)? /triage needs-information
Thanks for looking into it . You are indeed correct in your assumption that I'm using a which stores the token in the after retrieval. I'd love to learn why this should not be done, but the problem remains also without persisting the token after retrieval.

Basically the steps to reproduce could be reduced to these: containing an expired token. same configuring an exec plugin which retrieves a valid token out of band and echoes it. Expected behavior: The valid token retrieved is used for the subsequent authentication. Possibly expected behavior: The exec plugin flow not started (or exited with a warning) due to an expired token being present in the . Current behavior seems to acknowledge the invalid token and hence tries to retrieve a new, valid one - which it then discards as soon as it arrives.
Seems we can reduce it even further by removing the token altogether from the file and instead provide it directly. So the only step needed to reproduce is essentially this: configuring an exec plugin which retrieves a valid token out of band and echoes it as part of an . Now any will trigger the exec plugin to retrieve a valid token, but will still not use it for subsequent authentication.
This one is caused by config merging with clientcmd overrides: and exec.Auth not being in this switch:
Interesting, thanks Will add it to the switch along with some tests and if everything works out well I'll submit a PR next week.
Having spent some time on this in the debugger, it seems somewhat more intricate than I first thought. Turns out the exec plugin is executed whether the presented is invalid or valid - the exec action is actually called before the first call is even dispatched. This due to the exec credential plugin possibly being needed to setup the client certificate requested for the transport. Once the exec plugin's is called it assign the authenticators function to : ..which is then called when setting up the transport, thus triggering the exec plugin regardless of a token being present or not: Since the exec plugin has no way of knowing whether a token or a client certificate will be returned by the exec action, this kind of makes sense. It however defeats letting any present to override the exec plugin, which clearly seems to be the intent: Possible options here that I can think of: (and fix) behavior of letting override the exec plugin. This looks doable by adding a check for token auth early in the 's method body: But might be there are consequences to this I'm not aware of. the behavior of letting override the exec plugin being called.

third, more complex option, would be to keep the token override but dispatch to the exec credential plugin should the response from the first call with the token come back with a 401. This was what I originally believed was the intent as my first tests always included an invalid token. While this behavior seems nice I'm more and more thinking it may violate the principle of least surprise. Either you present a token and use that for auth or you let the exec plugin fetch the credentials for you. What do you guys think?
As a colleague just made me aware of, certain tools like kubetail seem to have kubectl call the exec plugin so many times that eventually the threshold of 1000 is reached and warn logs (exec:201) start spewing - even though no certificate (and hence no rotation) should be involved. This has me more convinced that the first option is the right one, skipping the client TLS ceremonies should a token be present for authentication.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale


Question: } By("Waiting for the target pod to stop running") <del> waitErr := f.WaitForPodNoLongerRunning(pod.Name) </del> <ins> if err := f.WaitForPodNoLongerRunning(pod.Name); err != nil { framework.Failf("Pod did not stop running: %v", err) } </ins> <del> By("Retrieving logs from the target pod") </del> <ins> By("Verifying logs") </ins> logOutput, err := framework.GetPodLogs(f.Client, f.Namespace.Name, pod.Name, "portforwardtester") if err != nil { <del> framework.Failf("Error retrieving logs: %v", err) } if waitErr != nil { framework.Logf("Pod log:n%s", logOutput) framework.Failf("Pod did not stop running: %v", waitErr) </del> <ins> framework.Failf("Error retrieving pod logs: %v", err) </ins> } <del> By("Verifying logs") </del> verifyLogMessage(logOutput, "Accepted client connection") verifyLogMessage(logOutput, "Done") })

https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Two hunks (2x 10 "x"s) are not sent back. extends the logging. At least it will tell us whether the sender gets an error or not.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
No more insights here. Pod log doesn't show anything special.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
I analysed this flake instance: https://k8s- It looks like the pfpod container terminates, the kubelet realizes that and wants to remove the network interface from the net ns using CNI via kubenet.

This fails two times (somehow TeardownNetwork is called multiple times, succeeds twice, but fails after that; compare about multiple TeardownNetwork calls). These failures interrupt the kubelet's tries to kill the pod. It succeeds 30 seconds later during reconciliation. But at that point the e2e test timed out already waiting for the pod to terminate.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
This is the real problem, not another flake: This happens roughly once per week, pretty stable.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.

Builds: kubernetes-e2e-gce-etcd3 kubernetes-e2e-gci-gce-kubenet kubernetes-e2e-gci-gce-release-1.4 kubernetes-e2e-gci-gke-multizone kubernetes-e2e-gci-gke-prod-smoke kubernetes-e2e-gci-gke-staging-parallel kubernetes-e2e-gci-gke kubernetes-e2e-gke-staging-parallel kubernetes-e2e-gke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: kubernetes-e2e-gci-gke-staging-parallel kubernetes-e2e-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: kubernetes-e2e-aws kubernetes-e2e-gci-gke-prod-smoke kubernetes-e2e-gke-staging-parallel kubernetes-e2e-gke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.

https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-gci-gke-release-1.4 kubernetes-e2e-gci-gke-staging-parallel kubernetes-e2e-gke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
any updates on this issue
No, no further insights. Feel free to invest some time here with some new ideas.

[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-gce-multizone kubernetes-e2e-gci-gce-kubenet kubernetes-e2e-gci-gce-proto kubernetes-e2e-gci-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: kubernetes-e2e-gci-gce-proto kubernetes-e2e-gci-gke-release-1.4 kubernetes-e2e-gci-gke-staging-parallel kubernetes-e2e-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-aws kubernetes-e2e-gci-gce-kubenet Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.

This needs to be triaged as a release-blocker or not for 1.5
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-aws ci-kubernetes-e2e-gci-gce-kubenet Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
or Can you help us triage this as blocking or non-blocking for 1.5. It was originally marked as non-blocking for the 1.4 release.
The initial triage done by sttts@ is still valid even though we changed something in TeardownNetwork logic in 1.5 release. I don't think this should be release blocker with the same reason provided by sttts@ for 1.4 release. But instead of asking timestclair@ to take further look, I am assigning this to cc/
I marked this as release-blocker just for triage here. Thanks!
Thanks can you take a look and retriage if needed.
We have two flakes here: -- that's what and is about, i.e. Teardown logic. happened 3 times in last 8 days, much less the days before. IMO this is not a blocker. -- this seems to happen multiple times a day when a lot of e2e tests are running. This is the actual network flake. I will try to look into one of those to understand whether there is anything non-network related we can fix.
Here is a debug PR running the flaking test 100 times: None failed until now. Moreover, 200 runs locally do not fail.
Another observation: the number of returned is always a multiple of 10. The test container sleep for 100ms after each 10 . So, this might be a hint that there is some kind of race closing the connection.

Builds: ci-kubernetes-e2e-aws ci-kubernetes-e2e-gci-gke-multizone ci-kubernetes-e2e-gci-gke-prod-parallel ci-kubernetes-e2e-gci-gke-staging-parallel ci-kubernetes-e2e-gci-gke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-aws ci-kubernetes-e2e-gci-gce-release-1.4 ci-kubernetes-e2e-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-aws ci-kubernetes-e2e-gce-release-1.5 ci-kubernetes-e2e-gci-gce-proto ci-kubernetes-e2e-gci-gce Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gce-etcd3 ci-kubernetes-e2e-gci-gce-etcd3 ci-kubernetes-e2e-gci-gce-kubenet Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Looks like this got a lot worse on 12/3 - https://k8s- Any chance this is related to
yes, it is most probably related to . In fact, was meant to make connection closing much less aggressive on the server side. It looks like our half-open connection support using socat is far from stable. I have in flight which is blocked by broken socat. Maybe that will help eventually to fix this flake.

Builds: ci-kubernetes-e2e-gce-etcd3 ci-kubernetes-e2e-gci-gce ci-kubernetes-soak-gke-test Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Bumping to P0 - this is happening pretty much all the time now. yes, it is most probably related to . - can we revert that PR then? Or have a fix really soon, this is the biggest trigger of failures now.
we marked both tests as last night: This shouldn't happen anymore after rebasing PRs.
Here is a first attempt for a real fix:
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
We will re-enable this test via This is also supposed to include a fix. Revert if the issue reappears.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Is it appropriate to move this to the next milestone? (and remove the non-release-blocker tag as well)
Builds: ci-kubernetes-e2e-gci-gce-release-1.4 ci-kubernetes-e2e-gci-gce-release-1.5 Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-release-1.4 ci-kubernetes-e2e-gci-gke-staging-parallel Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends data, and disconnects [Conformance] {Kubernetes e2e suite}
Closing this issue as the corresponding test has been removed from cc:


Question: __EOF__ } <ins> # Run it if: # 1) $WHAT is empty # 2) $WHAT is not empty and kubeadm is part of $WHAT WHAT=${WHAT:-} if [[ ${WHAT} == "" || ${WHAT} =~ .*kubeadm.* ]] ; then kube::log::status "Running kubeadm tests" run_kubeadm_tests # if we ONLY want to run kubeadm, then exit here. if [[ ${WHAT} == "kubeadm" ]]; then kube::log::status "TESTS PASSED" exit 0 fi fi </ins> kube::log::status "Running kubectl tests for kube-apiserver" setup

this PR removed the script which can be used to run the integration tests. the following command is claimed to be a replacement: but instead it runs unrelated tests too. expecting the above command to only show the following output (run only kubeadm tests): /assign
GitHub didn't allow me to assign the following users: runyontr. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : this PR removed the script which can be used to run the integration tests. but instead it runs unrelated tests too. /assign </details
/sig cluster-lifecycle
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Hey! Gentle reminder that code freeze is this Friday. Since this is part of the 1.14 milestone, is it going to be resolved soon?
hopefully in the next couple of days. PR is here:


Question: counter += 1 clone, _ := conversion.NewCloner().DeepCopy(pvc) newPvc, _ := clone.(*api.PersistentVolumeClaim) <del> newPvc.ObjectMeta = api.ObjectMeta{Name: fmt.Sprintf("fake-pvc-%d", counter)} </del> <ins> newPvc.ObjectMeta = api.ObjectMeta{Name: fmt.Sprintf("fake-pvc-race-%d", counter)} </ins> claim, err := testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(newPvc) if err != nil { t.Fatal("Error creating newPvc: %v", err) } claims = append(claims, claim) } <ins> glog.V(2).Infof("TestPersistentVolumeBindRace claims created") </ins> // putting a bind manually on a pv should only match the claim it is bound to rand.Seed(time.Now().Unix())

Test failed with and the relevant part of the stack trace is: Logs:
(or anyone), integration tests do not log much and I don't know what's going on in volume controller. Would it be possible to raise integration test log level at least to v=3 (4 preferred)?
what is the status of
can you please take a look?
Increasing integration log level can go into I think. It's probably a good idea to split them into their own job.


Question: if pod == nil { return fmt.Errorf("pod is missing, skipping (%s/%s)", addr.TargetRef.Namespace, addr.TargetRef.Name) } <del> if pod.Status.PodIPs[0].IP != addr.IP { return fmt.Errorf("pod ip doesn't match endpoint ip, skipping: %s vs %s (%s/%s)", pod.Status.PodIPs[0].IP, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </del> <ins> for _, podIP := range pod.Status.PodIPs { if podIP.IP == addr.IP { return nil } </ins> } <del> return nil </del> <ins> return fmt.Errorf("pod ip(s) doesn't match endpoint ip, skipping: %v vs %s (%s/%s)", pod.Status.PodIPs, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </ins> } // This is O(N), but we expect haystack to be small;

Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
I think the following should fix the error you saw:
/remove-sig api-machinery


Question: // "stdin closed", but hasn't exited yet. // We wait 10 seconds before printing to give time to kubectl to attach // to the container, this does not solve the race though. <del> runOutput = framework.NewKubectlCommand(ns, "run", "run-test-2", "--image="+busyboxImage, "--restart=OnFailure", "--attach=true", "--leave-stdin-open=true", "--", "sh", "-c", "sleep 10; cat && echo 'stdin closed'"). </del> <ins> framework.NewKubectlCommand(ns, "run", "run-test-2", "--image="+busyboxImage, "--restart=OnFailure", "--attach=true", "--leave-stdin-open=true", "--", "sh", "-c", "cat && echo 'stdin closed'"). </ins> WithStdinData("abcd1234"). ExecOrDie(ns) <ins> runOutput = waitForStdinContent("run-test-2", "stdin closed") </ins> gomega.Expect(runOutput).ToNot(gomega.ContainSubstring("abcd1234")) gomega.Expect(runOutput).To(gomega.ContainSubstring("stdin closed")) gomega.Expect(c.CoreV1().Pods(ns).Delete(context.TODO(), "run-test-2", metav1.DeleteOptions{})).To(gomega.BeNil()) ginkgo.By("executing a command with run and attach with stdin with open stdin should remain running") <del> runOutput = framework.NewKubectlCommand(ns, "run", "run-test-3", "--image="+busyboxImage, "--restart=OnFailure", "--attach=true", "--leave-stdin-open=true", "--stdin", "--", "sh", "-c", "cat && echo 'stdin closed'"). </del> <ins> framework.NewKubectlCommand(ns, "run", "run-test-3", "--image="+busyboxImage, "--restart=OnFailure", "--attach=true", "--leave-stdin-open=true", "--stdin", "--", "sh", "-c", "cat && echo 'stdin closed'"). </ins> WithStdinData("abcd1234n"). ExecOrDie(ns) <ins> runOutput = waitForStdinContent("run-test-3", "abcd1234") gomega.Expect(runOutput).To(gomega.ContainSubstring("abcd1234")) </ins> gomega.Expect(runOutput).ToNot(gomega.ContainSubstring("stdin closed")) g := func(pods []*v1.Pod) sort.Interface { return sort.Reverse(controller.ActivePods(pods)) } runTestPod, _, err := polymorphichelpers.GetFirstPod(f.ClientSet.CoreV1(), ns, "run=run-test-3", 1*time.Minute, g) framework.ExpectNoError(err)

The test case "executing a command with run and attach without stdin" is inherently racy. The test runs, and expected to see in the output. The case when the test passes: case 1: Kubernetes creates and starts the container without stdin; The container exits before attach runs; kubectl falls back to get container log, which contains . case 2: Kubernetes creates and starts the container without stdin; kubectl attach before "stdin closed" is printed; kubectl attach contains . The case when the test fails: Kubernetes creates and starts the container without stdin; The container prints "stdin closed", but hasn't exited yet; kubectl attach contains nothing. One example failure: Related issue: Can we modify this test not to check the output? Or use to check output instead? /cc
Uploaded to try to address
/reopen This test is still inherently racy, even after
Fix in (I hope!)
Moving into the current milestone as it was not fixed in 1.14
Hello I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 3 days from now). Do we still target this issue to be fixed for 1.16?
Thanks . PR is available and awaiting review!
What is the PR in question? Is it targeting 1.16 or 1.17?
/reopen This test is having a lot of failures these days
Reopened this issue. <detailsIn response to : /reopen 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
is right, it seems to be present in kind jobs now only
/assign let's see if we start to recover a bit of stability :smile:
The rate of failures decreased a lot since last changes Checking the logs of the failures it seems that the problem is that the pod has not finished before checking the output, as Lantao described The test fails Collecting events from namespace The framework logs the pods the kubelet thinks is on the node
note that it's still racy, but it's hopefully somewhat mitigated.
/reopen
Reopened this issue.

<detailsIn response to : /reopen 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
any updates here?
nope, totally agree with the description, is racy by design, couldn't find any way or trick to avoid the randomness
EDIT: It's late and I'm actually not sure I'm remembering this correctly, take this comment with a heap of salt: Specific sub-tests were fixed previously I think, but this one sub-case: That one we can't use the "Wait for stdin input to signal we're attached" hack, so it's just racy and broken. We could remove that case maybe. I'm not sure who I'd want to weigh in on that, probably someone more active in node / CLI.
not super common atm but still happening. discussing
/unassign has a fix for this


Question: return p.Update(realPet, pet) } if p.blockingPet != nil { <del> glog.Infof("Create of %v in PetSet %v blocked by unhealthy pet %v", pet.pod.Name, pet.parent.Name, p.blockingPet.pod.Name) return nil </del> <ins> message := errUnhealthyPet(fmt.Sprintf("Create of %v in PetSet %v blocked by unhealthy pet %v", pet.pod.Name, pet.parent.Name, p.blockingPet.pod.Name)) glog.Info(message) return message </ins> } // This is counted as a create, even if it fails. We can't skip indices // because some pets might allocate a special role to earlier indices.

Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned


Question: import ( "path" <ins> "reflect" </ins> "testing" ) <ins> // TestNewCgroupName tests confirms that #68416 is fixed func TestNewCgroupName(t *testing.T) { a := ParseCgroupfsToCgroupName("/a/") ab := NewCgroupName(a, "b") expectedAB := CgroupName([]string{"a", "", "b"}) if !reflect.DeepEqual(ab, expectedAB) { t.Errorf("Expected %d%+v; got %d%+v", len(expectedAB), expectedAB, len(ab), ab) } abc := NewCgroupName(ab, "c") expectedABC := CgroupName([]string{"a", "", "b", "c"}) if !reflect.DeepEqual(abc, expectedABC) { t.Errorf("Expected %d%+v; got %d%+v", len(expectedABC), expectedABC, len(abc), abc) } _ = NewCgroupName(ab, "d") if !reflect.DeepEqual(abc, expectedABC) { t.Errorf("Expected %d%+v; got %d%+v", len(expectedABC), expectedABC, len(abc), abc) } } </ins> func TestCgroupNameToSystemdBasename(t *testing.T) { testCases := []struct { input    CgroupName

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Setting a Resource requests and limits on a Pod other Pods running on the node where it was scheduled are moved to the cgroups created to serve the QoS request. What you expected to happen: Pods to stay in their assigned cgroups. How to reproduce it (as minimally and precisely as possible): kubelet running with the following flags: Create a pod without resource reservations and then create another one with resource reservations. For example, using the following template: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig node
This is the memory cgroup tree layout before starting an pod with resource request and limits. This is after the pod is created. Notice that is moved to the cgroup where nginx is running in
Interesting, since is running as a static pod
/milestone v1.12
this looks off... can you provide the output for the kube-proxy yaml file? what container runtime is being used? can you share the kubelet configuration?
We need to figure out if this is a regression in 1.12. Can you take a look?
I can reproduce it on GCE:
Node with same flags, except , instead of `--cgroup-root="/dashpole/" So the problem only occurs when is specified
I can reproduce this on 1.11.3 as well. I don't think this is a regression with the 1.12 release, although it is still a serious bug.
Correct, was being specified in the case above. As mentioned over Slack, we were able to track it back to 1.11.0-beta (can't recall the beta version, though) but not 1.11.0-alpha.2. The only PR we've identified which could have an impact is .
I will try to take a look today. I am curious the motivation for changing the cgroup-root, in retrospect, would have preferred we didnt expose it.
I am unable to reproduce this using systemd cgroup driver when using Given this exists currently in 1.11, we should fix this, but it should not block 1.12 milestone.
Thanks /priority important-soon
can you help to reproduce?

is OOO until Monday.
i just ran out of time to validate this with alternate driver (had assumed it would have happened with both), but it appears localized to one.
Nevertheless it's a good datapoint, it means it's only affecting cgroupfs driver. Regarding your question, the cgroup-root flag was the cleanest way we could find to have the kubelet respect the Mesos cgroup setup. Lmk if I can help you with anything.
ping , is this on track for 1.13? any related PRs?
I haven't looked deeper into this yet. Ill keep this on my list for 1.13
any porgress on this ? I don't see any associated PRs linked here. We are nearing code slush for 1.13 next Friday 11/9 and Code freeze in 2 weeks. If you think this issue isn't critical for 1.13 and work might extend beyond code slush please work with Niko Pen to move this out. thanks
Ill pick up this work over the next few days
I have narrowed it down to this strange behavior in golang: Basically, appending to a list constructed with has different behavior than appending to a list constructed literally, but only with lists where the size is larger than 1... This strange behavior with golang slices results in the "best-effort" qos cgroup in the qosContainerManager being changed to a pod's cgroup.
A simpler reproduction case:


Question: "github.com/golang/glog" ) <ins> func calculatePercentage(requested, capacity int) int { if capacity == 0 { return 0 } return (requested * 100) / capacity } </ins> // Calculate the occupancy on a node.  'node' has information about the resources on the node. // 'pods' is a list of pods currently scheduled on the node. func calculateOccupancy(node api.Minion, pods []api.Pod) HostPriority {

HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.


Question: renameContextLong = templates.LongDesc(` Renames a context from the kubeconfig file. <del> CONTEXT_NAME is the context name that you wish change. </del> <ins> CONTEXT_NAME is the context name that you wish to change. </ins> NEW_NAME is the new name you wish to set.

What happened: I noticed a typo when glancing at What you expected to happen: A diff of help would explain it best, I think. (old = current, new = desired) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I've got a PR ready. Environment: Kubernetes version (use ): v1.14.1 Cloud provider or hardware configuration: not applicable OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others:
/sig docs
/sig cli


Question: container.Args = []string{ "mounttest", fmt.Sprintf("--new_file_0644=%v", file), <del> fmt.Sprintf("--file_mode=%v", file), </del> } <ins> // See issue https://github.com/kubernetes/kubernetes/issues/94237 about file_mode // not working well on Windows // TODO: remove this check after issue is resolved if !framework.NodeOSDistroIs("windows") { container.Args = append(container.Args, fmt.Sprintf("--file_mode=%v", file)) } </ins> } func addSubpathVolumeContainer(container *v1.Container, volumeMount v1.VolumeMount) {

On a K8s Windows cluster, try to run container with agnhost image with following yaml file but failed Seems like --file_mode does not work well. Windows Server 2019
I retried the test mentioned in the issue on the latest kubernetes 1.19, but it did not reproduce. Here are my specific steps(I have a network problem and cannot access normally, so I use instead of ) the pod yaml The pod is running normally, and the directory on the windows node is successfully created ! I am more confused, can you help me see what is inconsistent with your test?
Could you try this? I copied it from one of the subPath test
What is behind this pvc, is there its yaml and the yaml corresponding to pv?
that is a pvc which points to a gce persistent disk.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
This issue doesn't seem to be fixed yet. /reopen /remove-lifecycle rotten
Reopened this issue. <detailsIn response to : This issue doesn't seem to be fixed yet. /remove-lifecycle rotten 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
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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


Question: } } <del> func TestImageCacheReturnCopiedList(t *testing.T) { cache := &imageCache{} testList := []container.Image{{ID: "1"}, {ID: "2"}} cache.set(testList) list := cache.get() assert.Len(t, list, 2) list[0].ID = "3" assert.Equal(t, cache.get(), testList) } </del> func uint64Ptr(i uint64) *uint64 { return &i }

See Today kubelet image manager returns the internal image list cache to caller directly. However, in we sort the image list, which introduces a data race. We should let image manager return a copy of image list instead of returning the list directly. /cc
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
Code Freeze for 1.10 begins in 2 hours. If this issue represents a bug or change for 1.10, then it needs SIG approval in the form of a status/approved-for-milestone label. It also needs a priority/ Thanks!


Question: }, }, }, <del> numErrs: 1, </del> <ins> numErrs: 0, </ins> }, { name: "same port in use, but not external",

From a user: I'm trying to expose multiple services on the same port in a GKE Kubernetes 0.8.1 cluster. My question is similar to this SO post but it is not solved by 0.5.x+ I've deployed a service (hellogo) with an external load balancer which works correctly. Deploying another service (pynote) which is extremely similar fails { "apiVersion": "v1beta1", "kind": "Service", "id": "pynote-service", "selector": { "name": "pynote" }, "containerPort": 8080, "protocol": "TCP", "port": 80, "createExternalLoadBalancer": true } gcloud preview container services --cluster athena --zone $ZONE create --config-file pynote- ERROR: F0124 19:42:27. ] service "pynote-service" is invalid: service "pynote-service" cannot be updated: port: 80 is already in use If I delete the other service and start pynote first, the service and load balancer are setup correctly, but the other service cannot be deployed with the same error. I believe the current proxying design is that service routing occurs via proxies on every node which are part of the target pool. Every service gets its own IP. Putting up two external services on port 80 on GKE should allocate two load balancers, each with a fixed IP address. This design does not preclude exposing services on the same port as each service is accessed through a separate external IP. Furthermore, Kubernetes itself runs a service (kubernetes-ro) on port 80 which coexists with my first service nicely. At the very least, the message is misleading. There is no requirement that the services deployed on a cluster use unique ports. In the source, it becomes apparent that its the external load balancer creation that causes the command to fail. Indeed, I can deploy pynote with createExternalLoadBalancer to false.

Happily coexisting: hellogo-service <nonename=hellogo 10.143.249.126 80 pynote-service <nonename=pynote 10.143.254.255 80 I've tried to define my own target pool called pynote-service, selecting all the cluster node instances and created a network load balancer with a forwarding rule on port 80 to the target pool. Despite the fact that it corresponds to the one created automatically for hellogo-service, it does not seem to resolve to the running pynote pod. This feels like I'm missing something small, but I've been blocked on this. Perhaps I'll only ever run one lonely web service...
I believe there's a bug in the service validation logic, left over from when you actually might have a conflict...


Question: - /heapster - --source=kubernetes.summary_api:'' - --sink=influxdb:http://monitoring-influxdb:8086 <del> - image: gcr.io/google_containers/heapster-amd64:v1.5.0-beta.0 </del> <ins> - image: gcr.io/google_containers/heapster-amd64:v1.5.0-beta.1 </ins> name: eventer command: - /eventer

I also hit when running cri-containerd as the container runtime. The reason is that we don't populate stats like in cri-containerd integration now. is adding the containerd support in cadvisor, after that we should have full summary metrics. However, heapster should not panic in this case anyway. Can we cut a heapster patch release and update heapster in the main repo?
+1. Many new CRI integration would run into this issue.
In fact, as far as I am aware, not a single CRI implementation currently implements any of the stats calls.
I beg to differ: That's the reason why filed the issue.
Yeah does implement the CRI stats. Currently it only support core metrics, which is only part of summary api. We are working on integration with cadvisor, before that some fields in summary api such as will be nil. Current heapster version will crash when is nil, which shouldn't happen. :)
/cc
My bad, thanks for the pointer :slightlysmilingface:. I'll correct my statement: I believe no CRI implementation except for cri-containerd implements the stats calls. The ones I explicitly checked are: dockershim, cri-o, rktlet.
Something I'm wondering about though: The intention of the stats calls is in order to be able to get rid of cAdvisor. Making the stats calls depend on cAdvisor seems to cover up the issues it has. Re:
Here is the reason that we still have to integrate with cadvisor for now.
/cc
If I understand correctly this is meant as a migration mean, so that both are possible for some time, and then we drop cAdvisor once a reasonable migration period has been granted.
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I will take a look at Heapster and try to fix this. Can you advise how to reproduce the issue?

This will help a lot with debugging and verifying a fix once it's ready.
this is already fixed at head and 1.4.3 version of heapster The problem that is using kubernetes version from head and we have there 1.5.0-beta.0: I see two possible solutions: version of heapster to 1.4.3 at head of kubernetes. Piotr mentioned that 1.5.0 has still a lot of problems, so it maybe makes sense. a new release of heapster (1.5.0-beta.1) and after that bump version at head.
And thanks for taking this issue.
Not directly related to this issue: a more general discussion is at We'd like to understand which fields are required and optional in heapster, so that we won't crash heapster with partial result.
We've merged a work around for now Hopefully it works. But anyway, we should fix this in 1.9.
what needs to be done for 1.9 here?
we'll need an assignee as well
We just need to update heapster version.


Question: filegroup( name = "all-srcs", <del> srcs = [":package-srcs"], </del> <ins> srcs = [ ":package-srcs", "//staging/src/k8s.io/apimachinery/pkg/conversion/unstructured/testing:all-srcs", ], </ins> tags = ["automanaged"], )

Kubernetes version (use ): master. What happened: Unstructured converter from does not roundtrip . What you expected to happen: When I call on a which is backed by it should basically make a copy of the content (can be optimized btw using deep copy ) and not a json object with key. How to reproduce it (as minimally and precisely as possible): See the test in my branch Test output: Anything else we need to know: For some reason changed the argument types from to . I guess the intent is to make the converter a more generic tool. But based on the previous signature I assume I'm doing the right thing. Actually, my code works with and I don't know if the actual object behind the interface is an or not - I just pass it to the converter and it works for usual API types, but not for unstructured. Also it would be useful to have a more type-safe version of the converter (i.e. the previous signature) that just delegates to a lower-level converter that does not care about types.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery
/kind bug
/assign
Looked into this issue just now. It is caused by the pointer vs non-pointer receiver of the method - similar to . In detail: is passed as to when it calls passing as . if passed value implements (has method ) does not implement this interface, does. Because on it . So perhaps the fix is to do the dereferencing inside of the ? Or maybe the same way as - check if the value is addressable, get a pointer to the value and then see if it matches the interface (I dunno if it will work that way)? In any case, the check whether a value implements the interface should be done on both the value itself () and the pointer to the value (; if the value is addressable) to cover both valid cases. This is what stdlib package does. Right now it is broken - it dereferences the pointer and then checks if the thing implements the interface. Does it make sense?

Reiterating the mentions to trigger a notification: <detailsIn response to : 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
does this helps? Look like we need to do MarshalJSON on non-pointers for it to work. I didn't get into the details but if that is the case then making Unstructured's MarshalJSON() receiver, a object instead of pointer should fix your problem, right?
Only if we don't fix the actual cause of the bug which I described above. From the stack overflow question that is mentioned in the link you provided: This code is buggy - to work it should be passing into and into . Yes, json package tries to take the address of the passed (so a pointer receiver should satisfy the interface check) but it cannot take an address of a function argument ( will return false). So, pointer receiver will be invoked if either is a field in a struct (so that an address can be taken via reflection) and a struct is passed (either by value or via a pointer) to / OR is passed. Please take a look at - both issues have the same cause.
I'm happy to take a stab at it and submit a PR but I don't want to spend my time if it is not going to get merged - if we could merge first to make sure people who can approve/lgtm are happy with the approach taken. I strongly believe it is the right thing to do - that is how standard library does it and, well, it is just logical and makes sense :)


Question: // CreateRoute in the cloud environment. func (g *Cloud) CreateRoute(ctx context.Context, clusterName string, nameHint string, route *cloudprovider.Route) error { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("create")

What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale