Question: } } <ins> for _, turnOff := range []bool{true, false} { // Turn off for checking if exist return true if turnOff { _, _ = vm.PowerOff(ctx) } exist, err := vm.Exists(ctx) if err != nil { t.Error(err) } if !exist { t.Errorf("exist=%t, expected=%t", exist, true) } // Turn back on if turnOff { _, _ = vm.PowerOn(ctx) } } </ins> for _, expect := range []bool{true, false} { active, err := vm.IsActive(ctx) if err != nil {

<!-- 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: We have k8s cluster with version . And I noticed that if I deleted worker node VM from IAAS, then node stuck in state, I created statefulset before and the pod scheduled on that node was stuck in state, and no new pod was created to replace that. Node should be deleted if no instance is found Related log When I check the log of I could see following log keeps popping up. Looks like node_controller noticed that the VM is gone but it doesn't delete the node. Related code here will return if no instance is found. But it should check if it's VM is deleted not shutdown, then return And it should cherry pick this fix avoiding deleting shutdown node What you expected to happen: After VM is deleted, the node should be deleted, pods assigned to the node should be rescheduled to other available nodes How to reproduce it (as minimally and precisely as possible): k8s cluster. In our case we use PKS. workloads on node worker node VM from IAAS Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig cloud-provider /sig vmware
Same issue as this one The issue and is cluster API repo. We should fix it inside node_controller in k/k
Hi this issue was found when testing windows cluster deployed using PKS. We do have a workaround by manually deleting node using kubectl. Still we wish the fix could go in ASAP. Could you ask someone from upstream to to review the PR that fix this issue? Thank you
, we will try to push this through for v1.20. 1.19 is approaching code thaw, so we can't push this through
Thanks Michael. I'll let my team know.
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: } // Return the plugin's client pod spec. Use an InitContainer to setup the file i/o test env. <del> func makePodSpec(config framework.VolumeTestConfig, dir, initCmd string, volsrc v1.VolumeSource, podSecContext *v1.PodSecurityContext) *v1.Pod { volName := fmt.Sprintf("%s-%s", config.Prefix, "io-volume") </del> <ins> func makePodSpec(config framework.VolumeTestConfig, initCmd string, volsrc v1.VolumeSource, podSecContext *v1.PodSecurityContext) *v1.Pod { </ins> var gracePeriod int64 = 1 <ins> volName := fmt.Sprintf("io-volume-%s", config.Namespace) </ins> return &v1.Pod{ TypeMeta: metav1.TypeMeta{ Kind:       "Pod",

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent


Question: "k8s.io/api/admissionregistration/v1beta1" "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/runtime/schema" <ins> utilruntime "k8s.io/apimachinery/pkg/util/runtime" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/version"

When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted


Question: // that we should check is if the "pod" is failing to schedule due to pod affinity // failure. // TODO(bsalamat): Consider checking affinity to lower priority pods if feasible with reasonable performance. <del> if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false); !fits { </del> <ins> if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false, nil); !fits { </ins> if err != nil { glog.Warningf("Encountered error while selecting victims on node %v: %v", nodeInfo.Node().Name, err) }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc


Question: dir = strings.TrimSuffix(pathdir, "/") mount, found = i.mounts[dir] } <ins> return &mount, found } func (i *RealFsInfo) GetDirFsDevice(dir string) (*DeviceInfo, error) { buf := new(syscall.Stat_t) err := syscall.Stat(dir, buf) if err != nil { return nil, fmt.Errorf("stat failed on %s with error: %s", dir, err) } // The type Dev in Stat_t is 32bit on mips. major := major(uint64(buf.Dev)) // nolint: unconvert minor := minor(uint64(buf.Dev)) // nolint: unconvert for device, partition := range i.partitions { if partition.major == major && partition.minor == minor { return &DeviceInfo{device, major, minor}, nil } } mount, found := i.mountInfoFromDir(dir) </ins> if found && mount.FsType == "btrfs" && mount.Major == 0 && strings.HasPrefix(mount.Source, "/dev/") { <del> major, minor, err := getBtrfsMajorMinorIds(&mount) </del> <ins> major, minor, err := getBtrfsMajorMinorIds(mount) </ins> if err != nil { klog.Warningf("%s", err) } else {

<!-- 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: Kubelet v1.19.0 doesn't start on nodes with CRI-O 1.17.2 (storagedriver="btrfs") with BTRFS as root filesystem. Related/previous issues: This error shows up in the journal: The is referring to the btrfs root filesystem, mounted at the time. : : What you expected to happen: Kubelet starts and detects the filesystem backing , even if it is BTRFS. How to reproduce it (as minimally and precisely as possible): Install kubeadm/kubectl 1.19.0 Install CRI-O, I used 1.17.2 from: Configure CRI-O to use Perform "kubeadm init" creating a new cluster Observe journal (check for kubelet issues) Anything else we need to know?: A possible workaround is to make sure a bind mount exists which allows kubelet's logic to find the backing fileystem. Eg. add the following fstab entry and then perform : The resulting mount should look somewhat like this: The workaround has been tested and seems to make kubelet work as expected. Environment: Kubernetes version: 1.19.0 OS: Debian Bullseye (Testing) Kernel: Linux 5.8.5 Others: The package has been installed
/sig node
cc xref
I am encounter the same issue. thank you for your workaround. It seems to work.
I got the same issue with latest stable Docker on Debian (btrfs) and k8s v1.19.2.
I confirm the same issue shows up with on btrfs (on LVM on LUKS, Debian buster), running k3s. No btrfs subvols. The workaround works for me; for k3s I also need to bind mount . I did not experience this issue with 1.18.
This also reproduces with Docker runtime. Workaround with bind mount helps, however automatically unmounts it so don't get confused. is on root that is mounted like this: , and docker is configured to use .

Reproduced with k8s 1.19.3 on Gentoo. The rootfs is btrfs, is on rootfs, docker is configured with storage drigver . automatically mount and unmount it on . Also confirmed bind mount workaround helps.
/assign
I think almost anyone using BTRFS as the root filesystem has encountered this issue. If is merged and applied to the kubernetes, this can be fixed. Please take a look at this ?
The has been merged to google/cadvisor. I think if Kubernetes v1.21 includes the fix by using google/cadvisor v0.39, the issue will be resolved.
Just a note that I too have stumbled on this issue after reconfiguring CRI-O storage to use btrfs driver pointing with graphroot directly to a BTRFS subvolume (the root filesystem is not BTRFS). After reading this issue I tried mounting the BTRFS subvolume explicitly on some mountpoint and pointed with graphroot to this explicit subvolume mountpoint which solved the problem. The problem seems to occur only when pointing to a subvolume within some parent subvolume as this is not a real mountpoint.
Ok, so I just want to make sure I understand. Currently when i try to run kubeadm to create a new cluster while using btrfs, it gives me With Kubernetes v1.21, that will no longer be the case?
In my experience (with CRI-O 1.19 and k8s 1.19), the btrfs driver (in ) is supported, but the combination does not work correctly when graphroot is pointed to a btrfs subvolume within some parent subvolume (I don't have experience with graphroot poited to some subdirectory of a default subvolume and/or when default subvolume is also a root filesystem, just when pointed directly to a subvolume within some parent subvolume which is not a root filesystem). For example, when btrfs filesystem is mounted like the following (): when I then create a subvolume: then use it as a graphroot (): But when I explicitly mount the subvolume to some mountpoint (): then use the explicitly mounted path as the graphroot (): it works correctly without any problems.

I guess some logic (either in CRI-O/containers or in kubelet) tries to find the "mountpoint" of the filesystem used for graphroot or something related and can't do that correctly when graphroot is located in a btrfs subvolume that is not explicitly mounted somewhere.
Ah, I see what you meant by saying that is not supported in . I haven't checked that since I created k8s clusted with default (overlay) driver and later migrated to . It is possible that disallows using because of problems like the one described above. But in my experience, when a subvolume is mounted explicitly, the btrfs works as expected - at least I didn't have problems with it.
Can the fix be backported to 1.19? only supports updating one version at a time: () So this leaves people on btrfs with with no upgrade path to which is not really nice.
We've discussed this issue at Regarding Maybe, there are quite a lot of people using btrfs than I expected. What do you think about this? Thanks!
I am running up against this issue as well. I am stuck with using k8s on 1.18
It sounds like for full fix we'll need to cherrypick to be included in k8s 1.19 and 1.20. To do that the following is needed: to cAdvisor v0.37 and v0.38 branches k8s 1.19 uses cAdvisor v0.37.3 - k8s 1.20 uses cAdvisor v0.38.6 - new cAdvisor patch release for v0.37 and v0.38 against k8s on 1.19 and 1.20 bumping to newly released cAdvisor (v0.37 / v0.38) with the fix I'm happy to cut the new cAdvisor release from my side if you want to proceed and think this is critical enough bug that is worth cherrypicking.
New cAdvisor patch versions have been cut with the BTRFS fix: v0.37.4 - v0.38.7 - /cc


Question: "//test/e2e/framework/providers/vsphere:go_default_library", "//test/e2e/framework/testfiles:go_default_library", "//test/e2e/manifest:go_default_library", <ins> "//test/e2e/reporters:go_default_library", </ins> "//test/utils:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library", "//vendor/github.com/onsi/ginkgo/config:go_default_library",

What would you like to be : I would like a method of seeing more clear data while tests are running, e.g.: How many tests will be run, have been run, have passed, have failed, etc. Name of the tests passed/failed/skipped Why is this needed: While a run is going we only have the output from stdout to investigate. There is a LOT of noise in those logs which is great for debugging after the fact, but difficult to consume most of the time. you can't tell how many tests have been run or get a sense of how much time is left you cant easily get a list of all tests that have failed so far My proposal Adding a new, custom ginkgo reporter that will post the data to a given URL (passed via a flag) if the URL isn't set, the reporter is a noop and doesn't waste time/resources Use cases: A user runs the tests dumps stdout to a file for debugging later, meanwhile they run a local server that will just echo the status updates it gets. At any point they look at the output they can get good data about what would be run, how far along it is, how successful it has been so far. Using the conformance test image and Sonobuoy, the Sonobuoy worker can act as the server, taking those status updates and reporting them to the aggregator. This would allow Sonobuoy to present that information to users on demand or stream it depending on the context. The work of adding this is pretty minimal and is clearly useful. In the case of Sonobuoy; this has been the most requested feature for a long time showing that people in the community really do want to have a better high-level picture of the progress of these tests. I think emitting the data to an endpoint like this is a flexible implementation that can help any consumer of the tests (not just Sonobuoy).
/sig testing /area test /area test-framework
One notification URL should work fine. Can you give me details on the data model for the status data to be published?
That is one, slightly TBD area. The reporter in the test framework has a bunch of data and I'm not sure what we exactly Sonobuoy may want from any given plugin (not just the e2e plugin).

I don't want this implementation to be overly Sonobuoy specific or overly e2e specific. Will update when something more clear is pinned down.
Brought this up in the testing commons meeting and it was agreed that this approach seemed reasonable and that the customReporters seemed like the only way to generate this data. In addition, it was requested that we find a way to also emit this (or some variation) into stdout/logs so that it is easier for a human to navigate those verbose logs.
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: // Find all sibling pods in the service and post to their /write handler. func contactOthers(state *State) { defer state.doneContactingPeers() <del> token, err := ioutil.ReadFile("/var/run/secrets/kubernetes.io/serviceaccount/token") if err != nil { log.Fatalf("Unable to read service account token: %v", err) } cc := client.Config{ Host:        "https://" + net.JoinHostPort(os.Getenv("KUBERNETES_SERVICE_HOST"), os.Getenv("KUBERNETES_SERVICE_PORT")), Version:     "v1beta3", BearerToken: string(token), Insecure:    true, // TOOD: package certs along with the token } client, err := client.New(&cc) if err != nil { log.Fatalf("Unable to create client:nconfig: %#vnerror: %vn", err) } if v, err := client.ServerVersion(); err != nil { log.Fatalf("Unable to get server version: %vn", err) } else { log.Printf("Server version: %#vn", v) </del> <ins> masterRO := url.URL{ Scheme: "http", Host:   os.Getenv("KUBERNETES_RO_SERVICE_HOST") + ":" + os.Getenv("KUBERNETES_RO_SERVICE_PORT"), Path:   "/api/" + latest.Version, </ins> } <ins> client := &client.Client{client.NewRESTClient(&masterRO, latest.Version, latest.Codec, false, 5, 10)} </ins> // Do this repeatedly, in case there's some propagation delay with getting // newly started pods into the endpoints list.

It's failing on both GCE and GKE-CI. It appears to have broken somewhere around build number 2509/2510 which includes a likely candidate PR (). /cc
I was about to debug this one. I'll take it.
Root cause is almost definitely one of these: Summary secrets example pod (details) the permissions on python files. (details) the implementation of DeepCopy to use reflection instead of Gob encode/decode. (details) networking test (details) back to executable. (details) protected docker processes (-900) (details) proxySocket out of to (details) Commit by Fix secrets example pod The file was modified Commit by Fixing the permissions on python files. The file was modified cluster/juju/charms/trusty/kubernetes- The file was modified cluster/juju/return-node- The file was modified cluster/juju/charms/trusty/kubernetes- Commit by Changing the implementation of DeepCopy to use reflection instead of Gob encode/decode. The file was The file was modified The file was modified Commit by Fix networking test The file was modified contrib/for-tests/network- The file was modified contrib/for-tests/network- The file was modified The file was modified contrib/for-tests/network-tester/Makefile Commit by Changing back to executable. The file was modified Commit by OOM protected docker processes (-900) The file was modified The file was modified The file was modified Commit by Move proxySocket out of to Moves proxySocket out of to new in proxy package in order to start separating proxy logic and implementation and make proxier more manageable to review. The file was modified The file was
Pretty sure it's commit , so rolling back now. cc .
The above rollback solved that immediate problem, but now the test, while proceeding healthily, is timing out. More debugging or optimization required: Networking should function for intra-pod communication ..... [irrelevant stuff deleted] ..... INFO: Proxy status call returned in 4.861944ms INFO: Attempt 35/60: test still running INFO: About to make a proxy status call Build timed out (after 90 minutes). Marking the build as aborted. Build timed out (after 90 minutes). Marking the build as failed. Ran 40 of 46 Specs in 5069.444 seconds FAIL!

-- 18 Passed 5 Skipped Build was aborted Recording test results
I'm not entirely sure why, but the test is running normally again, completing consistently in 13 seconds. Closing this issue for now. !


Question: // update the status condition to false. The function returns a bool to let the // caller know if the list was changed (either appended or updated). func ensureJobConditionStatus(list []batch.JobCondition, cType batch.JobConditionType, status v1.ConditionStatus, reason, message string) ([]batch.JobCondition, bool) { <del> for i := range list { if list[i].Type == cType { if list[i].Status != status || list[i].Reason != reason || list[i].Message != message { list[i].Status = status list[i].LastTransitionTime = metav1.Now() list[i].Reason = reason list[i].Message = message return list, true } return list, false </del> <ins> if condition := findConditionByType(list, cType); condition != nil { if condition.Status != status || condition.Reason != reason || condition.Message != message { *condition = *newCondition(cType, status, reason, message) return list, true </ins> } <ins> return list, false </ins> } // A condition with that type doesn't exist in the list. if status != v1.ConditionFalse {

If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.


Question: return waitForPodTerminatedInNamespace(f.ClientSet, podName, reason, f.Namespace.Name) } <ins> // WaitForPodNotFound waits for the pod to be completely terminated (not "Get-able"). func (f *Framework) WaitForPodNotFound(podName string, timeout time.Duration) error { return waitForPodNotFoundInNamespace(f.ClientSet, podName, f.Namespace.Name, timeout) } </ins> // WaitForPodRunning waits for the pod to run in the namespace. func (f *Framework) WaitForPodRunning(podName string) error { return WaitForPodNameRunningInNamespace(f.ClientSet, podName, f.Namespace.Name)

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: See One /sig storage
/assign
[Slow] test suite was run. Glusterfs io stream test failed due to ns not being deleted, which was due to 1 pod remaining. The glusterfs-server pod was deleted. It appears that the glusterfs-client pod was not deleted even though returned no error. In cases where this test succeeds (which is most of the time) returns which is seen in the log as INFO: Ignore "not found" error above. Pod "gluster-io-client" successfully deleted. Sometimes when the plugin io streaming tests pass you'll see logged for the client pod. However, sometimes a client pod is deleted but the above log entry is not triggered. Eg in you'll see the nfs-client pod is deleted (the ns was able to be deleted) yet the above log msg stating to ignore the "not found" error was not generated. (scroll down to the line "I0724 20:27:20.364] Jul 24 20:27:00.559: INFO: Waiting for pod nfs-io-client in namespace 'e2e-tests-volume-io-pmdks' status to be 'terminated due to deadline exceeded'(found phase: "Running", readiness: true) (29.883170178s elapsed) I0724 20:27:20.365] [AfterEach] [sig-storage] NFS"). My guess is that in this case the plugin's client pod did not terminate in 30s -- WHY NOT THE FULL 5m? -- but did terminate in time for the ns to be deleted. And sometimes the client pod cannot be deleted in 30s (again WHY NOT THE FULL 5m?) and is still present when the ns is deleted. Note: if we cannot detect that the client pod was not actually deleted and then we delete the server pod, there is no chance that the ns can be deleted. Once the server pod is gone the client pod will not delete.
It looks like the client pod failed to terminate:
30s may not always be enough time for the gluster client pod to terminate?

also, why is it so common to see ~29 seconds for the client pods (nfs, gluster) to supposedly terminate. The wait should be for up to 5m yet I never see = 30s wait times... yet, we know that sometimes the gluster client pod is not terminated. Seems like maybe a bug in this area?
can you take a look? My findings so far are this test fails about 20% of the time. The gluster client pod's Status is set to Failed and therefore the pod won't be deleted. There is e2e code that waits for the pod to be deleted but escapes if the pod has "Failed" and if the passed-in reason matches the pod's Status.Reason. In the gluster pod test failures the pod's Status.Reason == "". This causes the test to incorrectly assume that the pod was deleted when it wasn't. This problem manifests itself when the namespace is deleted and that step fails. It seems like the Failed pod's Status.Reason should not be blank. cc
It looks like gluster unmount failed:
But in the log I looked at today (https://k8s-) I see the pod's Status=Running. Then the pod is deleted and the status remains Running for ~30s then changes to Failed. Even though the pod is Failed its Reason remains "". So 1) I wonder why the pod is marked as Running if its mount failed, and 2) once the pod is Failed why is Reason still blank?
It was the unmount that failed, not the mount.
ah, ok thanks, I missed that. Still need to know why Pod.Status.Reason is blank...
Below are some records from a related to the glusterfs-client pod, gluster-io-cliente2e-tests-volume-io-6h140(-778e-11e7-afad-)_ and the "e2e-tests-volume-io-6h140" ns:
I think the issue is that the test is deleting the gluster endpoints before deleting the pod.
Nm, the test does seem to be cleaning up in the correct order: client pod, then server pod and endpoints. So the issue seems to be that during Pod termination, it goes to Failed state.

Before, I thought it was because the unmount failed, but based on the timestamps of the logs, it seems like it fails before we start unmounting.
Just spoke to and he said that it's normal for a Pod to go to Failed state during the termination sequence. In between Failed state and Pod object deletion is when we unmount the volumes. So I think the issue here is that the WaitForPodTerminated function needs to wait only for the Pod object to be deleted, and not return early if Pod state is Failed.
do you have time to look at this? The test is still flaking
yes I can take a look. Do you know if there has been a pr started to address this issue? BTW, I will be gone most of tomorrow but will start tomorrow night.


Question: echo '    make test-integration' echo echo "The following invocation will run a specific test with the verbose flag set: " <del> echo '    make test-integration WHAT=./test/integration/pods KUBE_GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </del> <ins> echo '    make test-integration WHAT=./test/integration/pods GOFLAGS="-v" KUBE_TEST_ARGS="-run ^TestPodUpdateActiveDeadlineSeconds$"' </ins> echo exit 1

We should just use GOFLAGS
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 contributor-experience
/assign


Question: framework.ExpectEqual(namespace.ObjectMeta.Labels["testLabel"], "testValue", "namespace not patched") }) <del> ginkgo.It("should apply changes to a namespace status", func() { </del> <ins> /* Release: v1.25 Testname: Namespace, apply changes to a namespace status Description: Getting the current namespace status MUST succeed. The reported status phase MUST be active. Given the patching of the namespace status, the fields MUST equal the new values. Given the updating of the namespace status, the fields MUST equal the new values. */ framework.ConformanceIt("should apply changes to a namespace status", func() { </ins> ns := f.Namespace.Name dc := f.DynamicClient nsResource := v1.SchemeGroupVersion.WithResource("namespaces")

[x] test approval issue : [x] test pr : [x] two weeks soak end date : 1 Aug 2022 [x] test promotion pr : According to this APIsnoop query, there is still some remaining NamespaceStatus endpoints which are untested. readCoreV1NamespaceStatuspatchCoreV1NamespaceStatus Using a number of existing e2e test practices a new has been created for 2 namespace status endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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


Question: return } w.Header().Set("Content-Type", "application/json") <ins> glog.Infof("Writting status code: %d", statusCode) </ins> w.WriteHeader(statusCode) w.Write(formatted.Bytes()) }

If go-restful detects a particular method is not allowed, it will return this error: That is preventing useful methods that resthandler would generate from making it to the client. Expected response:
triggered with
/cc
/cc
Is the right fix to update the client to generate the message versus changing the server to allow the method and report the error? My bias is to improve the client and not change the server as it makes reading our swagger doc easier to not see a bunch of verb unsupported entries. Sent from my iPhone
My bias is also towards not changing the server to keep swagger spec correct. By changing the client, do you mean changing kubectl? can you please clarify how is the json useful to client? It does not contain any useful extra information. On Feb 11, 2015 7:28 PM, "Derek Carr" wrote:
Returning an API response would allow clients that expect API status to get nice messages for free, instead of spitting this out: We can certainly put the burden of interpreting 405 errors on all clients, just seemed nice not to. Also, since the resthandler code expected to be returning API status responses when the method wasn't supported, I wanted to make sure having go-restful intercept and return 405's instead wasn't left as an unintended and unconsidered side-effect.
This was an unintended side effect, but I think the old behavior was an unexpected luxury? I agree from the end-user perspective, the old message was nice, and it's great that the client was politely told that a given verb was not supported on the resource, but I don't agree that a server should appear to accept a method to only report that its not allowed. ----- Original Message ----- From: "Jordan Liggitt" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Thursday, February 12, 2015 1:04:41 PM Subject: Re: [kubernetes] go-restful is emitting less helpful errors than resthandler () Returning an API response would allow clients that expect API status to get nice messages for free, instead of spitting this out: We can certainly put the burden of interpreting 405 errors on all clients, just seemed nice not to.

Also, since the resthandler code expected to be returning API status responses when the method wasn't supported, I wanted to make sure having go-restful intercept and return 405's instead wasn't left as an unintended and unconsidered side-effect. Reply to this email directly or view it on GitHub:
If we want to leave go-restful returning that as an intended and considered side-effect, that's fine. Is the consensus that this issue should change to update kubectl to show a nicer message for that error?
I think so, this is only going to get worse when we support specific types of verbs on specific resources. In practice, it seems fine for kubectl to give a better error specific to the method not allowed response. ----- Original Message ----- From: "Jordan Liggitt" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Thursday, February 12, 2015 1:26:08 PM Subject: Re: [kubernetes] go-restful is emitting less helpful errors than resthandler () If we want to leave go-restful returning that as an intended and considered side-effect, that's fine. Is the consensus that this issue should change to update kubectl to show a nicer message for that error? Reply to this email directly or view it on GitHub:
We could consider submitting a PR to go-restful to allow us to provide an error-generation function or interface implementation.
Yeah, that seems reasonable.
Opened
Copying text from : Some errors return as json and some as plain text. This causes overhead on client side when parsing the errors since need to recheck content type for every error in order not to parse plain text as json (some libraries fail on that). The errors message format should be standardized. Examples: The text/plain errors are from go-restful. cc
+1, thanks
The status objects are always of the default API version, however, rather than the version requested, because the request object isn't available to the error handler.
Rather than: we need:
Can we define an error handler on a web service?
At the moment, it's at the container level:
David and I talked about keeping the API lookup mechanism so we could use that in the error handler (apirequestinfo). We still need it for some use cases (proxies) so it could be used here to identify the version and proposed resource if matched.


Question: }, }, }, <ins> // List pods as impersonated user. { func() { _, err = impersonatedClient.CoreV1().Pods(namespace).List(metav1.ListOptions{}) framework.ExpectNoError(err, "failed to list pods") }, []utils.AuditEvent{ { Level:              auditinternal.LevelRequest, Stage:              auditinternal.StageResponseComplete, RequestURI:         fmt.Sprintf("/api/v1/namespaces/%s/pods", namespace), Verb:               "list", Code:               200, User:               auditTestUser, ImpersonatedUser:   "superman", ImpersonatedGroups: "system:masters", Resource:           "pods", Namespace:          namespace, RequestObject:      false, ResponseObject:     false, AuthorizeDecision:  "allow", }, }, }, </ins> } // test authorizer annotations, RBAC is required.

We don't currently have any test coverage of impersonation for audit logging. I think the audit e2e test () would be a good place to do so. /area audit /area test /sig auth /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : We don't currently have any test coverage of impersonation for audit logging. I think the audit e2e test () would be a good place to do so. /area test /sig auth /help /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
assign I would like to work on this issue. Please give me some tips and instructions which i should take into consideration and will help me accomplishing this task successfully.
Take a look at the existing audit tests (linked in description), and the documentation on . I recommended doing a manual test first, so you understand how it works. The audit test actually already uses impersonation (), so you can just do something similar and then verify that it is logged correctly (the field).
Also, if you need help with the e2e framework, is the place to start.
Ok, thank you :)
GitHub didn't allow me to assign the following users: loqutus. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign 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
How is it going? Do you need some help?
Just watch around.
I am pretty confused regarding how to write test cases
Can you give me more details about what it is you are struggling with? Writing test cases in general? I'm also new to the project but perhaps I can help you out. :)
Yes, I am struggling with writing test cases in general
Are you still struggling with test cases in general?

Please tell me if I am wrong, but I think here a test case is just testing that a particular call to the api logs specific information (represented by the struct AuditEvent). If I am correct, we don't need to create a complete new test case, but rather edit the exiting ones by checking one more info. Additionally, I am not sure that we can test this locally with kubetest, since the test seems to only accept the gce provider (google cloud engine). Hope this helps.
yes, I am struggling for writing test case as well as this was in my concious as well that how I am gonna test this test case
OK, I think I got what the issue is about. Please let me know if you are still struggling and prefer to hand it over. I'd like to give it a shot but don't want to steal the opportunity to make a first contribution to the project from you.
yaa sure you can give it a shot
FYI I'm working on this issue. I'm trying to get audit logging activated in minikube so I can manually test impersonation and see the log output (in order to see what the test has to cover). However, trying to get it activated in minikube is more difficult than I thought. :grimacing:
Hey how is it going with the manual test? The only way I found with minikube, is to start it with the following command (I use minikube v0.30.0). This activates audit logs, and configures the logs file path in the minikube's VM. Then you could use an api call using kubectl, with and without impersonation, and see the difference in logs. Notice that it does not matter if we have not created any pods at this point, because we just want to test the audit. To look into the logs you need to ssh into Minikube and look into a particular file. The manual test is a good thing to see how it works. But you don't actually need to code the whole thing, I think. as the current audit test already loads and parses the log file (see inside CheckAuditLines, and then parseAuditLine).
Hey , thanks for your extensive anser.

I managed to get in tested manually with minikube a couple of days ago, though it was not possible for me to get an costum audit policy file loaded even though it was available (somehow the extra config flag was ignored). Anyway, I spent the last couple of days figuring out how to best run the e2e tests on my macbook (I'm using Vagrant right now since there were some problems with running the tests in docker on mac). As you already mentioned in a previous comment, the audit tests only accept gce as a provider. I tried to simply comment that line out in order to see what happens if it runs on my local machine, but (unsuprisingly) it blew up. So the current status is, that I'm now trying to write the test case for impersonation relying on the CI to see if it runs through (since I cannot run the test locally) which is not ideal but I don't have a better idea atm.


Question: return err } mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). FilenameParam(filenames...).

I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR


Question: reportDir = flag.String("report-dir", "", "Path to the directory where the JUnit XML reports should be saved. Default is empty, which doesn't generate these reports.") ) <ins> type failReporter struct { failed bool } func (f *failReporter) SpecSuiteWillBegin(config config.GinkgoConfigType, summary *types.SuiteSummary) { } func (f *failReporter) BeforeSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecWillRun(specSummary *types.SpecSummary)         {} func (f *failReporter) SpecDidComplete(specSummary *types.SpecSummary) { if specSummary.Failed() { f.failed = true } } func (f *failReporter) AfterSuiteDidRun(setupSummary *types.SetupSummary) {} func (f *failReporter) SpecSuiteDidEnd(summary *types.SuiteSummary)       {} </ins> func init() { // Turn on verbose by default to get spec names config.DefaultReporterConfig.Verbose = true

We need to be able to diagnose e2e test failures after the relevant test cluster has been shut down. Right now this almost works, but not quite. Fluentd can currently only be configured to send log files to one place, for example: Cloud Logging, or (running as a pod in the e2e test cluster, and saved to local disk on the node). With the current configuration in , logs typically go to ElasticSearch (and there is an e2e test to check that that works correctly), and tears down the e2e test cluster after each test run, so the logs are deleted. The proposed solution is to have fluentd configurable to send to multiple log collector backends, and configure it as such to both Google Cloud Logging and ElasticSearch for CI e2e test runs to facilitate easier debugging. Satnam6502@ has offered to sort this out.
Originally it was possible to send logs to both Elasticsearch and Cloud Logging but at some point this got made into a binary choice of one or the other (by or ?). I propose to undo this unless there are strong objections. : what do you think?
I didn't turn it into a binary choice. :) , Satnam Singh wrote:
Yeah, pretty sure it was Joe. I am sure it was a wide decision at the time.
Would be nice to have these at maximum verbosity because when we need them we need them all, IIRC we currently only get V(2) on a kube-up cluster
I see this is marked as a post v1.0 milestone? If we don't want this urgently then I will un-assign myself for now.
There is a valid argument that we would not block the 1.0 release for lack of these persisted test logs, and hence the v1.0 milestone was tentatively removed. There is a counter argument that we stand little chance of being able to debug the existing and still-to-be-found flaky test failures in the absence of log files, and that one or more of those bugs, if not fixed, will block the launch anyway. I'd say that if there is nothing on the v1.0 milestone that you can sensibly work on, this one is fair game.

I would find it useful, and I suppose this should be on par with writing tests (of which we have a few 1.0: )
I'm not sure we'll be able to convince folks to move this to 1.0, but feel free to work on this, as it seems very valuable.
I thought about changing our setup to allow both Elasticsearch and Cloud Logging to be targeted. I've been a little hesitant because this could lead to a breakage (esp. for GKE) and we are getting close to 1.0 ...
/cc who might have memories about a GKE breakage caused by changes in env vars used for logging.
I'd love to see this fixed soon to help debug flakes, but yes, it'd be nice to at least be cc'ed on env var changes.
Try again to have it to the high priority list, as this is making debugging the system very difficult. cc Who expressed interest.
How do we access those logs? I tried to find them for gce-scalability jenkins suite, but didn't find it.


Question: creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <ins> name: system:aws-cloud-provider roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:aws-cloud-provider subjects: - kind: ServiceAccount name: aws-cloud-provider namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </ins> name: system:basic-user roleRef: apiGroup: rbac.authorization.k8s.io

Recently introduced fix of tainting the node if EBS volume on a node is stuck for too long in "attaching" state does not work on RBAC enabled clusters because of missing service account permissions. /sig storage /sig aws


Question: needToSetNewMapValue := currMapValue.Kind() == reflect.Invalid if needToSetNewMapValue { <ins> if unset { return fmt.Errorf("current map key `%v` is invalid", mapKey.Interface()) } </ins> currMapValue = reflect.New(mapValueType.Elem()).Elem().Addr() actualCurrValue.SetMapIndex(mapKey, currMapValue) }

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug


Question: } loadBalancerIP := service.Spec.LoadBalancerIP <del> if loadBalancerIP != "" { </del> <ins> if loadBalancerIP != "" && internalAnnotation { </ins> createOpts.VipAddress = loadBalancerIP }

Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently openstack cloud provider just support for specifying internal LoadBalancerIP. I think that is unreasonable, actually user just use a floating ip to access a LoadBalancer service. So it is necessary to spport for specifying external LoadBalancerIP. What you expected to happen: Support for specifying external LoadBalancerIP on openstack Anything else we need to know?: Currently LoadBalancerIP can be specified in service.Spec.LoadBalancerIP, we can add annotation to distinguish between internal and external.
/sig openstack /assign I'd like to work for it.


Question: // (+optional) Annotations defines the PVC's annotations type PersistentVolumeClaimConfig struct { <del> AccessModes []v1.PersistentVolumeAccessMode Annotations map[string]string Selector    *metav1.LabelSelector </del> <ins> AccessModes      []v1.PersistentVolumeAccessMode Annotations      map[string]string Selector         *metav1.LabelSelector StorageClassName *string </ins> } // Clean up a pv and pvc in a single pv/pvc test case.

For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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


Question: framework.Failf("Failed to find nginx ingress controller pods with selector %v", sel) } cont.pod = &pods.Items[0] <del> cont.externalIP, err = framework.GetHostExternalAddress(cont.Client, cont.pod) framework.ExpectNoError(err) framework.Logf("ingress controller running in pod %v on ip %v", cont.pod.Name, cont.externalIP) </del> <ins> framework.Logf("ingress controller running in pod %v", cont.pod.Name) </ins> } func generateBacksideHTTPSIngressSpec(ns string) *networkingv1beta1.Ingress {

Hello sig-network, We, sig-scalability, are exploring using "private" clusters (i.e. the ones where nodes don't have public IPs) for our large (up to 5K nodes) scalability tests to avoid consuming expensive public IPs. More details in With a few minor modifications we managed to get an almost passing correctness test suite on a private cluster except the 3 sig-network tests which explicitly assume that nodes are reachable over public IPs. Failing tests (): [sig-network] Firewall rule should have correct firewall rules for e2e cluster [sig-network] Loadbalancing: L7 [Slow] Nginx should conform to Ingress spec [sig-network] Services should be able to create a functioning NodePort service Could you take a look at them and advise if it would be possible to rewrite them so they can work both in the "public" and "private" clusters? We'd really appreciate your help assistance here. Let me know if you have any questions. Thanks, Matt
please triage /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
could you take a look?
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
After the conversation I had with I'm un-assigning to make it go through the regular triage process. /unassign It's not a super high priority, but would be great if someone from the sig-network team could take a look. This effort could potentially result in releasing over 10K of public IPs.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
want to track this one with the release team as well as it is showing up in /priority critical-urgent /milestone v1.16
could we get someone to look into these issues or get an update of when we might get some news?
Reiterating the mentions to trigger a notification: <detailsIn response to : could we get someone to look into these issues or get an update of when we might get some news?

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
should we add a new TAG on tests that does not apply to private clusters?
would adding tags to the tests skip private clusters entirely? I would think ideally private clusters should still have tests... if that's correct who would be responsible for adding more tests?
Hey Folks, sorry I must have missed updates here. I don't think that this should block 1.16 in any way nor it should be marked as priority/critical-urgent. This is an experimental test suite that we run in order to stop using public ips in scalability tests. What's more only 3 out of over 800 tests fail for private clusters and I'm quite confident that these tests don't fail because of a bug in kubernetes, but rather because they are written in a way that assumes that each node will have a public IP. The only action item here is to rewrite the tests and make them compatible with private clusters. I opened the bug to get some insights from sig/network on that as all failing tests belong to them. Removing the milestone and changing the priority, let me know if someone doesn't agree. /priority important-soon /milestone clear
/remove-priority critical-urgent
Thank you for the updates. I understand the test suite is experimental and there is a high level of confidence that the handful of failing sig-network jobs are failing due to the test suite and not to Kubernetes itself but given that this affects the quality of the signal we get from CI signal for this release we want to maintain it in the 1.16 milestone. could you bring this up with (don't see a group for test failures)? /milestone v1.16
friendly ping about this, would you be able to assign the correct person to write tests for this?
Let's bring this up in the sig-network meeting to see if we have any volunteers
Any updates on this issue?


Question: var iscsiTransport string var lastErr error <del> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.Iface, "-o", "show") </del> <ins> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.InitIface, "-o", "show") </ins> if err != nil { <del> klog.Errorf("iscsi: could not read iface %s error: %s", b.Iface, string(out)) </del> <ins> klog.Errorf("iscsi: could not read iface %s error: %s", b.InitIface, string(out)) </ins> return "", err }

What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign


Question: // communicate with the API server. func NewNoExecuteTaintManager(c clientset.Interface) *NoExecuteTaintManager { eventBroadcaster := record.NewBroadcaster() <del> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "controllermanager"}) </del> <ins> recorder := eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "taint-controller"}) </ins> eventBroadcaster.StartLogging(glog.Infof) if c != nil { glog.V(0).Infof("Sending events to api server.")

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: kubect create -f to create statefulset, and describe the statefulset, output the event likes <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 statefulset Normal SuccessfulCreate create Claim www-web-0 Pod web-0 in StatefulSet web success 1m 1m 1 statefulset Normal SuccessfulCreate create Pod web-0 in StatefulSet web successful </preWhat you expected to happen: the From of event change to 'statefulset-controller' in output, let know the source of event more obvious, likes the event when create job and other resource(replicaset,replication). <preEvents: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 3m 3m 1 job-controller Normal SuccessfulCreate Created pod: pi-7gd2m </preHow to reproduce it (as minimally and precisely as possible): create a statefulset and describe it to see the event Anything else we need to know?: Environment: Kubernetes version (use ):kubernetes 1.7 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/assign
/area controller-manager
/sig node


Question: match: GOLANG_VERSION=d+.d+(alpha|beta|rc)?.?d+ - path: staging/publishing/rules.yaml match: 'default-go-version: d+.d+(alpha|beta|rc)?.?(d+)?' <ins> - path: cluster/images/etcd/Makefile match: 'GOLANG_VERSION?=d+.d+(alpha|beta|rc)?.?(d+)?' </ins> # Golang pre-releases are denoted as `1.y<pre-release stage>.z` # Example: go1.16rc1

Right now the golang version in the Makefile is set to GOLANGVERSION?=1.12.17. Build fails with " undefined: errors.Is", presumably because errors.Is didn't exist in golang 1.12.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
I can take a look.
/triage accepted
According to , we should use 1.16. /kind bug /area release-eng
I send a fix. It would be good to make sure this doesn't break in the future. Question to How we can include building cloud/image as part of presubmits?
Somehow I thought maybe we'd switched to an ectd image built from the etcd project and needed to eventually drop this one? If not this is rather concerning. We don't have a great presubmit to shove this in, I would suggest a runifchanged presubmit to let reviewers of this image know if it builds w/o making it a required job on all PRs (since also changes should be scoped to a directory and infrequent).
For example the conformance image works this way


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

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


Question: tests := []struct { name               string registerPlugins    []tf.RegisterPluginFunc <ins> extenders          []tf.FakeExtender </ins> nodes              []string pvcs               []v1.PersistentVolumeClaim pod                *v1.Pod

When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/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
/sig scheduling
/reopen We'll close it when all cherry-picks are done.
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
/close Cherry-picks are done.


Question: client := ec2.New(session.New()) request := &ec2.CreateVolumeInput{} <del> request.AvailabilityZone = aws.String(TestContext.CloudConfig.Zone) </del> <ins> request.AvailabilityZone = aws.String(zone) </ins> request.Size = aws.Int64(10) request.VolumeType = aws.String(awscloud.DefaultVolumeType) response, err := client.CreateVolume(request)

For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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


Question: "github.com/google/go-cmp/cmp" "github.com/google/go-cmp/cmp/cmpopts" <del> "github.com/stretchr/testify/require" v1 "k8s.io/api/core/v1" </del> "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Graduate seccomp to GA, as defined on the respective . This is an umbrella issue to track all outstanding work. [x] API Server changes (MERGED) [x] Kubelet changes (MERGED) [x] Mark flag as deprecated (MERGED) [x] Update PSP to support seccomp fields (MERGED) [x] Document Kubernetes seccomp support (MERGED)[x] Add seccomp least privilege for docker sandbox (MERGED) [x] Add seccomp least privilege for kuberuntime (MERGED) ) /area kubelet /area kubelet-api /sig node /area security /assign
/cc
just a heads up that we have concluded all the core items for seccomp to go GA. There are still 2 pending PRs that ideally would also go in 1.19, but we are waiting for them to be reviewed: and
needs to be rebased apparently and isn't just waiting in the merge pool as verify is not passing.
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
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
I think the warning mechanism was blocked by a not existing API. This is now tracked in
/remove-lifecycle stale
Updated the description to given that the warning mechanism is now set to that milestone.
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/priority backlog
/triage accepted
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 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]:
/remove-lifecycle stale
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]:
/remove-lifecycle stale
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]:
/remove-lifecycle stale
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]:
/remove-lifecycle stale
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]:
/remove-lifecycle stale
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]:
/lifecycle frozen What is the remaining work here?
I guess we have to follow-up on and implement: I can take care of that if we agree that we want to ship that in 1.27. /cc


Question: allErrs = append(allErrs, field.Required(fldPath, provisioner)) } if len(provisioner) > 0 { <del> for _, msg := range validation.IsQualifiedName(strings.ToLower(provisioner)) { allErrs = append(allErrs, field.Invalid(fldPath, provisioner, msg)) } </del> <ins> allErrs = append(allErrs, apivalidation.ValidateQualifiedName(strings.ToLower(provisioner), fldPath)...) </ins> } return allErrs }

After got merged, we have new helper function here: It will be good for us to use this simpler helper function to replace previous function. /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : After got merged, we have new helper function here: </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 usability
I would like to take this one /assign
I worked in on this as well, but kept your changed files untouched (as written in my PR description). same for you. I hope this is OK for you.
This should be reopened until and got merged (my PR excluded the changes from the other PRs).
/reopen per last comment
Reopened this issue. <detailsIn response to : This should be reopened until and got merged (my PR excluded the changes from the other PRs). per last comment 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
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]:
can you assign me
/assign
/assign
I'd love to work on this issue.

/assign
Hi, , I am a first commitor for kubernetes and I have committed a PR in , could you help me to review it, or give me some suggestions. Thanks a lot.
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 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <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 or PR with Mark this issue or PR 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: cluster/kubectl.sh config set-credentials myself --client-key=/var/run/kubernetes/client-admin.key --client-certificate=/var/run/kubernetes/client-admin.crt cluster/kubectl.sh config set-context local --cluster=local --user=myself cluster/kubectl.sh config use-context local <del> fi </del>  No newline at end of file <ins> fi </ins>

/kind bug What happened: Start a cluster using ./hack/local- Now just monitor the memory on kube-apiserver and kube-controller-manager. Without doing anything else note the memory on each process has grown by 500 MB each day. Tried this for 5 days and saw this steady growth. What you expected to happen: Memory to remain relatively flat after some initial growth. How to reproduce it (as minimally and precisely as possible): Run ./hack/local- and wait. Anything else we need to know?: Environment: Kubernetes version (use ): 1.10 Cloud provider or hardware configuration: local OS (e.g. from /etc/os-release): Debian GNU/Linux Kernel (e.g. ): Debian 4.9.65-3+deb9u2 Install tools: Others:
/sig api-machinery
/milestone v1.10
/priority important-soon
!
Copying some of what was discussed in Slack - we need to redo a test with set when running . This disables the cache mutation detector, which holds on to "all the things" .
What does the chart mean? yeah determined that most of it is from the mutation detector (it really makes me nervous to have test code linked in to the production binaries).
It was a differential pprof memory chart of hack/local-cluster- But as noted, we have to run it without mutation detection. I did that for an hour yesterday and did not notice much memory leaking.
After the suggested fix (turn of mutation detection), there was no noticeable increase on controller manager memory and the api-server memory increase was down to 8 MB per day. (on my setup)
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 2 days, the issue will be moved out of the v1.10 milestone. <details<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
closing this to remove it from the release radar. Feel free to reopen if you think we still have an issue.


Question: if cachedVal.err != nil && isTransientError(cachedVal.err) { r, err := d.serverResourcesForGroupVersion(groupVersion) if err != nil { <del> utilruntime.HandleError(fmt.Errorf("couldn't get resource list for %v: %v", groupVersion, err)) </del> <ins> // Don't log "empty response" as an error; it is a common response for metrics. if _, emptyErr := err.(*emptyResponseError); emptyErr { // Log at same verbosity as disk cache. klog.V(3).Infof("%v", err) } else { utilruntime.HandleError(fmt.Errorf("couldn't get resource list for %v: %v", groupVersion, err)) } </ins> } cachedVal = &cacheEntry{r, err} d.groupToServerResources[groupVersion] = cachedVal

I think this got stale and closed because it was posted on but is still very relevant: The created by memory.NewMemCacheClient(...) returns an error when calling ServerResourcesForGroupVersion if the APIResources list returned is empty, as seen here: Our particular case came up due to the API group being registered with the API server, but having no resources. If using like to discover with zero current resources there should not be an error returned. Do a discovery with a against a Kubernetes cluster that has at least one with zero resources. The condition on the server that triggers the described issue can be expressed as e.g.: I would be good to get to know the reasoning behind the emptiness check in the , maybe there is good reason for it. <detailsClient Version: v1.20.15 Server Version: v1.22.8-gke.202 </details<detailsGoogle Cloud (GKE) </detailsNo response No response No response No response
/sig api-machinery
/cc /triage accepted
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]:
/remove-lifecycle stale
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]:
Reviving this issue based on This behavior has become quite annoying for the custom/external metrics aggregated APIs since after , client-go is now producing a very spammy error log when an aggregated API is found without resource. This is a very common scenario with the metric APIs since metrics are dynamically registered as Resources to the aggregated APIs so on startup the aggregated apiserver may not expose any resource and that's completely normal. It is even more common for implementations of these APIs that register metric Resources from CRDs as CRs tend to be created later than APIServices and the aggregated apiserver. I can see a few path forward to improve the situation for us: the error if we consider that having no resources exposed by an aggregated API is acceptable the verbosity of the log to just show it in debugging scenarios somehow update to defer registration until we have at least one Metric resource. could you perhaps share your insight on that one please? /remove-lifecycle stale
Hello folks! Any update on this topic? The message is really spammy
Removing triage accepted manually since there was no update on this for more than 6 months. /remove-triage accepted
For context, I traced it back and check has been considered an error since the first iteration of the in-memory discovery client in : It is unexpected for a built-in or CRD groupversion to have no resources, but for aggregated-apiservice I can see it being possible that the object is created and set up for discovery before the aggregated-apiservice is ready.
I think this is which introduces (but maybe I'm wrong). There is also in that repo about the same issue after upgrading the kube-client pkg. in custom-metrics repo be correct from Kubernetes pov? IMO we need to find a solution soon or the amount of noise will increase once people bump their deps and tooling (, kubectl is affected, and any tool which uses kube-client is affected)
/triage accepted


Question: framework.ExpectNoError(err, "start pod") } }) <ins> // This test covers aspects of non graceful node shutdown by DRA controller // More details about this can be found in the KEP: // https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown // NOTE: this test depends on kind. It will only work with kind cluster as it shuts down one of the // nodes by running `docker stop <node name>`, which is very kind-specific. ginkgo.It("[Serial] [Disruptive] [Slow] must deallocate on non graceful node shutdown", func(ctx context.Context) { ginkgo.By("create test pod") parameters := b.parameters() label := "app.kubernetes.io/instance" instance := f.UniqueName + "-test-app" pod := b.podExternal() pod.Labels[label] = instance claim := b.externalClaim(resourcev1alpha2.AllocationModeWaitForFirstConsumer) b.create(ctx, parameters, claim, pod) ginkgo.By("wait for test pod " + pod.Name + " to run") labelSelector := labels.SelectorFromSet(labels.Set(pod.Labels)) pods, err := e2epod.WaitForPodsWithLabelRunningReady(ctx, f.ClientSet, pod.Namespace, labelSelector, 1, framework.PodStartTimeout) framework.ExpectNoError(err, "start pod") runningPod := &pods.Items[0] nodeName := runningPod.Spec.NodeName // Prevent builder tearDown to fail waiting for unprepared resources delete(b.driver.Nodes, nodeName) ginkgo.By("stop node " + nodeName + " non gracefully") _, stderr, err := framework.RunCmd("docker", "stop", nodeName) gomega.Expect(stderr).To(gomega.BeEmpty()) framework.ExpectNoError(err) ginkgo.DeferCleanup(framework.RunCmd, "docker", "start", nodeName) if ok := e2enode.WaitForNodeToBeNotReady(ctx, f.ClientSet, nodeName, f.Timeouts.NodeNotReady); !ok { framework.Failf("Node %s failed to enter NotReady state", nodeName) } ginkgo.By("apply out-of-service taint on node " + nodeName) taint := v1.Taint{ Key:    v1.TaintNodeOutOfService, Effect: v1.TaintEffectNoExecute, } e2enode.AddOrUpdateTaintOnNode(ctx, f.ClientSet, nodeName, taint) e2enode.ExpectNodeHasTaint(ctx, f.ClientSet, nodeName, &taint) ginkgo.DeferCleanup(e2enode.RemoveTaintOffNode, f.ClientSet, nodeName, taint) ginkgo.By("waiting for claim to get deallocated") gomega.Eventually(ctx, framework.GetObject(b.f.ClientSet.ResourceV1alpha2().ResourceClaims(b.f.Namespace.Name).Get, claim.Name, metav1.GetOptions{})).WithTimeout(f.Timeouts.PodDelete).Should(gomega.HaveField("Status.Allocation", gomega.BeNil())) }) </ins> }) ginkgo.Context("with node-local resources", func() {

We need to explore how DRA interacts with One likely outcome is that the DRA helper code watches for nodes with the special label and helps DRA drivers clean up. /sig node
/assign
/triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29 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
/triage accepted
Here's a test that was written for volumes:
Thank you. I’ve found it last week. Unfortunately kind image doesn’t have ssh, so stopping kubelet is not possible the way this test does. I’ve found another solution.
I was able to simulate non-graceful node shutdown by running . It turned out that after adding tent, all node pods are deleted by the GC controller and the resource claim controller successfully deallocated the resource. So, it looks like a non-graceful shutdown is handled correctly and no code changes are required. However, the fact that can potentially be called without calling should be explained in the DRA KEP, so that DRA plugin authors will be aware of this. I'll add an explanation of handling non-graceful node shoutdown to the and add a correspondent e2e test case to the DRA e2e test suite.
KEP update PR: E2E PR:


Question: kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod # Create a role named "foo" with API Group specified <del> kubectl create role foo --verb=get,list,watch --resource=rs.extensions </del> <ins> kubectl create role foo --verb=get,list,watch --resource=rs.apps </ins> # Create a role named "foo" with SubResource specified kubectl create role foo --verb=get,list,watch --resource=pods,pods/status`))

create clusterrole command with resource value not work. I got this example command from the help note. But got error with the example command. I think it should work like yes. No response <details</details<detailsno cloud env, just vm </details<details</details<detailskubeadm </details<detailsClient: Version: 20.10.7 API version: 1.41 Go version: go1.13.8 Git commit: 20.10.7-0ubuntu5~20.04.2 Built: Mon Nov 1 00:34:17 2021 OS/Arch: linux/amd64 Context: default Experimental: true Server: Engine: Version: 20.10.7 API version: 1.41 (minimum version 1.12) Go version: go1.13.8 Git commit: 20.10.7-0ubuntu5~20.04.2 Built: Fri Oct 22 00:45:53 2021 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.5.5-0ubuntu3~20.04.2 GitCommit: runc: Version: 1.0.1-0ubuntu2~20.04.1 GitCommit: docker-init: Version: 0.19.0 GitCommit: </details<details</details
/sig CLI
/sig auth /assign
extensions/v1beta1 is no longer served since 1.16 the example should be updated to refer to
Thanks, for this information, I will update this. One more thing I have to ask here should I also do update the files/folders under folder like
Hi Any Inputs on this!
I don't know how the translation files are maintained, sorry
Don't be sorry, it's OK! Thanks!
/assign I will update the docs.
Hi I am already working on it. I have one doubt on translation files, which I already asked in the channel. Could you please tell me if you know that it will be a great help!
/usassign ok
You can check the kubectl example. ! And the role/clusterrole and something else alse needs an update.

Code in website: I think it is generated
yes, I already saw where to update the things, but I have one doubt in file which is under translation , I just wonder I have to update this file or not. see this
/cc
Hi PTAL!
Hi could you please take a look!
Hi Friendly reminder!
Fix it here PTAL!
/triage accepted


Question: Failf("Failed to find expected endpoints:nTries %dnCommand %vnretrieved %vnexpected %vn", maxTries, cmd, eps, expectedEps) } <del> func (config *NetworkingTestConfig) GetEndpointsFromTestContainer(protocol, targetIP string, targetPort, maxTries, minTries int) (sets.String, error) { return config.GetEndpointsFromContainer(protocol, config.TestContainerPod.Status.PodIP, targetIP, TestContainerHttpPort, targetPort, maxTries, minTries) </del> <ins> func (config *NetworkingTestConfig) GetEndpointsFromTestContainer(protocol, targetIP string, targetPort, tries int) (sets.String, error) { return config.GetEndpointsFromContainer(protocol, config.TestContainerPod.Status.PodIP, targetIP, TestContainerHttpPort, targetPort, tries) </ins> } <del> func (config *NetworkingTestConfig) GetEndpointsFromContainer(protocol, containerIP, targetIP string, containerHttpPort, targetPort, maxTries, minTries int) (sets.String, error) { </del> <ins> // GetEndpointsFromContainer executes a curl via kubectl exec in a test container, // which might then translate to a tcp or udp request based on the protocol argument // in the url. // - tries is the maximum number of curl attempts. If this many attempts pass and //   we don't see any endpoints, the test fails. func (config *NetworkingTestConfig) GetEndpointsFromContainer(protocol, containerIP, targetIP string, containerHttpPort, targetPort, tries int) (sets.String, error) { </ins> cmd := fmt.Sprintf("curl -q -s 'http://%s:%d/dial?request=hostName&protocol=%s&host=%s&port=%d&tries=1'", containerIP, containerHttpPort,

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /sig network What happened: From https://k8s-, seems to be broken right after they were by Example error message: and Anything else we need to know?: Is it as expected?
Oct 11 16:37:49.106: test session affinity, cost time: 1m31.742990485s This is a mistake. Sorry for my debug lines sneak in. I was just wondering why this test case doesn't run in upstream CI, so I this debug line. Now, I see because this test case only runs in . Oct 11 16:39:42.406: Expect endpoints: map[], got: map[netserver-1:{}] This check failed unexpectedly, let me try to find out why. I am working on it and will let you know soon when I have some updates.
Thanks. These two tests don't run on pull jobs as they are marked as , though https://k8s-, https://k8s- (and other CIs that include ) would have them running.
Do you mean when I raise a PR, these test cases will not be triggered? My question is how can I make sure my follow-up PR can fix this bug? Where can I access the log message when I raise a new PR?
Can I see the updated test results via directly visiting https://k8s-, https://k8s-
Yep, that is the current behavior. A hacky way to make it run on PR --- add a temporary commit to remove the word from test name so some pull jobs ( I think?) will run it. And you could view logs by clicking the button.
Nope, this CI only includes changes that are merged. It is basically a cronjob that runs tests against head.


Question: // DetachDisk unmounts and detaches a volume from node func (util *ISCSIUtil) DetachDisk(c iscsiDiskUnmounter, mntPath string) error { <del> _, cnt, err := mount.GetDeviceNameFromMount(c.mounter, mntPath) if err != nil { glog.Errorf("iscsi detach disk: failed to get device from mnt: %snError: %v", mntPath, err) return err } </del> if pathExists, pathErr := volumeutil.PathExists(mntPath); pathErr != nil { return fmt.Errorf("Error checking if path exists: %v", pathErr) } else if !pathExists { glog.Warningf("Warning: Unmount skipped because path does not exist: %v", mntPath) return nil } <del> if err = c.mounter.Unmount(mntPath); err != nil { </del> <ins> if err := c.mounter.Unmount(mntPath); err != nil { </ins> glog.Errorf("iscsi detach disk: failed to unmount: %snError: %v", mntPath, err) return err } <del> cnt-- if cnt != 0 { return nil } </del> // if device is no longer used, see if need to logout the target device, prefix, err := extractDeviceAndPrefix(mntPath) if err != nil {

Some mount propagation magic in Kubernetes on Ubuntu 16.04 on GCE duplicates every mount. Steps to reproduce: On recent master. install Kubernetes on GCE on Ubuntu: Run a pod with a GCE PD volume: The volume looks like it's mounted twice in output on the node: Deleting this pod will unmount everything correctly in GCE PD case, however it won't unmount Ceph RBD: There seems to be some bind-mount && rshared propagation magic happening in Google's helper mounter container that makes a mount appear twice. Note that MountPropagation and MountContainers are disabled in this cluster, so it can't be the culprit. I can probably fix reference counting in RBD, however this doubling of mounts looks very ugly and may have other consequences than just failed RBD teardown. /kind bug /sig storage
cc
I found the culprit, it's simple bind-mount , it's not just below it. Any mount in will appear twice in . It's enough to unmount it once, both of the mounts will then disappear. It's the same on GCI and on Ubuntu. We can either add an option to disable on Ubuntu or fix all the volume plugins not to depend on a volume mounted only once (e.g. ). Fixing the plugins will fix it on all deployments that may be bind-mounting stuff to weird places.
Hi Jan, I was trying to better understand --bind and --rbind in mount. Reading [1] I see the following: "Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command" Yet L1463 [2] and L14634 do exactly this, eg: mount --bind -o ro /proc "${CONTAINERIZEDMOUNTERROOTFS}/proc" Would you mind explaining? Thanks, Jeff [1] [2]
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 /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
sorry that I missed this issue earlier. Have you fixed it or is it still an issue?
I worked around it in


Question: local -r npd_version="${DEFAULT_NPD_VERSION}" local -r npd_hash="${DEFAULT_NPD_HASH}" fi <del> local -r npd_tar="node-problem-detector-${npd_version}.tar.gz" </del> <ins> local -r npd_tar="node-problem-detector-${npd_version}-${HOST_PLATFORM}_${HOST_ARCH}.tar.gz" </ins> if is-preloaded "${npd_tar}" "${npd_hash}"; then echo "${npd_tar} is preloaded."

/cc Can and npd v0.8.8(with ) fix this problem? /sig node Example: node-problem-  /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Yes, the and npd v0.8.8(with kubernetes/node-problem-detector) should fix this problem
/triage accepted /assign
There are other files that are needed to be updated, for reference Could you please update.


Question: "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/dockershim/network:go_default_library", "//pkg/util/bandwidth:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", </ins> "//vendor/github.com/containernetworking/cni/libcni:go_default_library", "//vendor/github.com/containernetworking/cni/pkg/types:go_default_library", "//vendor/k8s.io/klog:go_default_library",

What happened: When Node's iops is full, the Node status becomes to be NotReady. The NotReady message is "Container runtime is not ready". After our troubleshoot, we found func in cni package costs more then 30s, then the runtime status health check is failed : What you expected to happen: Node should still be in Ready status when iops is full. Because the CNI config files does not change. How to reproduce it (as minimally and precisely as possible): Run an application to fill disk IO bandwidth, then the Node becomes to be NotReady. Anything else we need to know?: Nothing yet. Environment: Runtime is dockershim. Other environment is no need to pay attention.
/assign /sig-node
/sig node /sig network