Question: return newObj, nil } <ins> eqFn := equalities.DeepEqual if _, ok := newObj.(*unstructured.Unstructured); ok { // Use strict equality with unstructured eqFn = equalities.DeepEqualWithNilDifferentFromEmpty } </ins> // This condition ensures the managed fields are always compared first. If //	this check fails, the if statement will short circuit. If the check // 	succeeds the slow path is taken which compares entire objects. <del> if !equalities.DeepEqualWithNilDifferentFromEmpty(oldManagedFields, newManagedFields) { </del> <ins> if !eqFn(oldManagedFields, newManagedFields) { </ins> return newObj, nil } <del> if equalities.DeepEqualWithNilDifferentFromEmpty(newObj, oldObj) { </del> <ins> if eqFn(newObj, oldObj) { </ins> // Remove any changed timestamps, so that timestamp is not the only // change seen by etcd. //

Every time I server-side apply a with , the updates. Nothing about my manifest changes between applies; if I map to the empty map, the same manifest updates the . With client-side apply, the stays the same as long as my manifest remains constant, even if . I read in that Kubernetes should treat absent keys, empty values (in this case, an empty map), and values the same. I observe that leaving the key out and behave as expected, not modifying the and leaving the same, but empty map behaves as described above. If we cannot change this behavior, I'd at least like to understand the rationale behind it. I expected my object to stay the same between identical server-side applies, where the manifest file content was exactly the same, regardless of the value of . A different every apply indicates that the object was event type . I expect no events to fire on applying the same manifest. contains In actuality, any is fine. . Every successive repeat of steps 3-4 should show different values. Example of with : This is especially a problem when I server-side apply with code in my operator. My operator is built on and watches changes to the child objects it deploys. If I create a with , the operator constantly reconciles because every server-side apply of the manifest registers as a type event on the object, which triggers the watching operator to reconcile. N/A <details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Potentially similar case as


Question: func (b *gcePersistentDiskMounter) SetUpAt(dir string, fsGroup *int64) error { // TODO: handle failed mounts here. notMnt, err := b.mounter.IsLikelyNotMountPoint(dir) <del> glog.V(4).Infof("PersistentDisk set up: %s %v %v", dir, !notMnt, err) </del> <ins> glog.V(4).Infof("PersistentDisk set up: %s %v %v, pd name %v readOnly %v", dir, !notMnt, err, b.pdName, b.readOnly) </ins> if err != nil && !os.IsNotExist(err) { return err }

Eg: Suspect it's because of:
If this hasn't been seen in 3 months, okay to close?
Yes we fixed it with


Question: if !ignoreNotReady { return errors.New(errorBadPodsStates(badPods, desiredPods, ns, "RUNNING and READY", timeout)) } <del> Logf("Number of not-ready pods is allowed.") </del> <ins> Logf("Number of not-ready pods (%d) is below the allowed threshold (%d).", notReady, allowedNotReadyPods) </ins> } return nil }

Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: This log seems to imply that we wait until less than some number of pods are un-ready, and yet the loop succeeds if there is no improvement. What you expected to happen: Either the loop should terminate earlier (if the condition is acceptable) or fail (if it's unacceptable).
/sig scalability since this probably most affects us
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


Question: fmt.Fprintf(o.ErrOut, "Warning: resource '%s' is not namespace scoped in group '%s'n", o.Resource.Resource, o.Resource.Group) } } <ins> if !isKnownResourceVerb(o.Verb) { fmt.Fprintf(o.ErrOut, "Warning: verb '%s' is not a known verbn", o.Verb) } </ins> } if o.NoHeaders {

<!-- 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: When using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb


Question: { name: "valid Unregister", registry: Registry{ <del> "pluginFactory1": NewMockNoopPluginFactory(), "pluginFactory2": NewMockNoopPluginFactory(), </del> <ins> "pluginFactory1": m1, "pluginFactory2": m2, </ins> }, nameToUnregister: "pluginFactory1", expected: Registry{ <del> "pluginFactory2": NewMockNoopPluginFactory(), </del> <ins> "pluginFactory2": m2, </ins> }, shouldError: false, },

<!-- 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 --Below are the failures while running unit test with golang in master branch. Reference : $ go version go version devel go1.17- Thu Apr 22 01:40:02 2021 +0000 linux/ppc64le Note: Occurs in x86 architecture as well. The tests should Pass as with stable go git clone cd kubernetes make test KUBERACE=-race WHAT=./pkg/scheduler/framework/runtime/ Master branch of kubernetes repo. OS: Linux Observed failure on ppc64le and x86 architectures Below is the attached log:
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
I request help on getting this triaged. Is there a procedure to follow to get this accepted as a bug?
The Go compiler developer has identified the bugs in the test that is causing it to fail. They are listed in the last comment in the Go issue before closing it.
So the correct way to compare function would be something like would you test it in your env?
The issue still exists. Can you please reopen?
I am not sure if you can access this link for our CI job. Can you please check? https://prow.ppc64le- The above tests have been failing every day in our jobs!
/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
downloads go from url="${GOLANGVERSION}.linux-" downloads go from "curl -X GET http://build-?project=build_commit -o " I suspect the postsubmit-master-golang-kubernetes-unit-test-ppc64le failed for wrong golang version.

failed for other problems. The TestMerge is not failed. For ppc64le failures, there are several issues in golang: (fixed yesterday)
Yes the go versions for both the jobs are different and it is intentional: : It is meant to run Kubernetes unit tests with the stable version of golang : It is meant to run Kubernetes unit tests with golang built from the master branch of As I mentioned in the description of this issue, these unit test cases are failing only on golang that is built from master branch and passing with stable versions of golang. And as Lynn mentioned in , the golang team has concluded that these failures are due to the bugs in the test case. And the golang issues that you mentioned do not seem to be related to the failures mentioned in this issue.
With , is false Per , do you mean that we should change to ?
No. In general comparing is the right thing to do. But if the Value is actually a , which is not comparable, comparing will panic.
/sig scheduling
Note from golang team about this bug is here:


Question: return err } if waitForReplicas != nil { <del> watchOptions := api.ListOptions{FieldSelector: fields.OneTermEqualSelector("metadata.name", name), ResourceVersion: updatedResourceVersion} watcher, err := scaler.c.ReplicationControllers(namespace).Watch(watchOptions) </del> <ins> checkRC := func(rc *api.ReplicationController) bool { if uint(rc.Spec.Replicas) != newSize { // the size is changed by other party. Don't need to wait for the new change to complete. return true } return rc.Status.ObservedGeneration >= rc.Generation && rc.Status.Replicas == rc.Spec.Replicas } // If number of replicas doesn't change, then the update may not event // be sent to underlying databse (we don't send no-op changes). // In such case, <updatedResourceVersion> will have value of the most // recent update (which may be far in the past) so we may get "too old // RV" error from watch or potentially no ReplicationController events // will be deliver, since it may already be in the expected state. // To protect from these two, we first issue Get() to ensure that we // are not already in the expected state. currentRC, err := scaler.c.ReplicationControllers(namespace).Get(name) </ins> if err != nil { return err } <del> _, err = watch.Until(waitForReplicas.Timeout, watcher, func(event watch.Event) (bool, error) { if event.Type != watch.Added && event.Type != watch.Modified { return false, nil </del> <ins> if !checkRC(currentRC) { watchOptions := api.ListOptions{ FieldSelector:   fields.OneTermEqualSelector("metadata.name", name), ResourceVersion: updatedResourceVersion, </ins> } <del> rc := event.Object.(*api.ReplicationController) if uint(rc.Spec.Replicas) != newSize { // the size is changed by other party. Don't need to wait for the new change to complete. return true, nil </del> <ins> watcher, err := scaler.c.ReplicationControllers(namespace).Watch(watchOptions) if err != nil { return err </ins> } <del> return rc.Status.ObservedGeneration >= rc.Generation && rc.Status.Replicas == rc.Spec.Replicas, nil }) if err == wait.ErrWaitTimeout { return fmt.Errorf("timed out waiting for %q to be synced", name) </del> <ins> _, err = watch.Until(waitForReplicas.Timeout, watcher, func(event watch.Event) (bool, error) { if event.Type != watch.Added && event.Type != watch.Modified { return false, nil } return checkRC(event.Object.(*api.ReplicationController)), nil }) if err == wait.ErrWaitTimeout { return fmt.Errorf("timed out waiting for %q to be synced", name) } return err </ins> } <del> return err </del> } return nil }

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle

30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
I'm pretty sure, those amount of failure are related to: (I don't know why yet).

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}


Question: List(filter string) ([]string, error) } <ins> // Zone represents the location of a particular machine type Zone struct { FailureDomain string Region        string } </ins> // Zones is an abstract, pluggable interface for zone enumeration. type Zones interface { <del> // GetZone returns the name of the current failure zone that the program is running in GetZone() (string, error) </del> <ins> // GetZone returns the Zone containing the current failure zone and locality region that the program is running in GetZone() (Zone, error) </ins> }

Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in


Question: return nil, errDeleteNow } lastGraceful = *options.GracePeriodSeconds <ins> lastExisting = existing </ins> return existing, nil }), )

cc
PTAL
The root cause is that the node controller and kubelet delete the pods using their names (they should use UID instead): (this is not an exhaustive list) In test-, we create and delete the same pod multiple times, so it's possible that the node controller or the kubelet sends a deletion request to the api server, with the intention of deleting the Nth occurrence of a pod, while it's actually deleting the N+1th occurrence of the pod. To reproduce the flake, I introduced a random delay between 500~1500 ms in the node controller's execution path (), then using a script to create/delete a pod repeatedly, and the flake will occur after several rounds.
Why is it not okay to delete by name?
namespace+name pair is not an unique identifier across time.
the client library and the API server don't support deletion by UID, I think we should support.
Thanks!! My thoughts: does node controller care about these pods? I'm pretty sure the original author wasn't expecting that. a temporary fix, is it hard to just use new names for every incarnation of these pods?
Deleting by UID is probably a bigger can of worms than we want to open right now, although it will eventually be important. Thinking out loud here, but maybe it'd be possible to add a resource version to the delete command. I.e., "delete only if it hasn't changed since rv=xxxxx". But I still think it's probably ideal to turn off the node controller for this test.
I'm also thinking if we can centralize all the pod deletion logic into kubelet, but it seems some of the logic need to stay in the node controller, e.g, , because only the node controller knows if the node exists. deletion probably can be done by the kubelet.
Looks like node controller is getting an update of the pod where DeleteionTimestamp is set, which seems like a bug if --grace-period is set to 0. My understanding is that if grace period is zero, the pod should get immediately deleted. That pod will never make it to a kubelet because it hasn't been scheduled yet. Thus which kubelet would delete it? I'm pretty sure none of those deletions can be handled in the kubelet.

Btw, when running hack/test- (), the node controller generates many messages about the failed deletions: or , these are because kubelet wins the race and has deleted the pods. These don't cause test- to fail.
per offline discussion with Mike, I think he's right. I'll check the api server's code.
That's my expectation, too (that grace period being zero should bypass all graceful deletion code and just immediately delete the pod).
When the grace period is zero, api server update the storage(), and then delete the pod from the storage (). The check of if grace period is 0 is after the update(). It seems it should not do the update if grace periods is zero.
Do you agree that the above is a bug?
Hm, is the problem a missing or incorrect BeforeDelete handler?
I think we are dealing with two problems here: grace-period=0, the registry shouldn't do an update. client library should provide a Delete() method that takes an unique identifier, the "name+namespace" pair is ambiguous across time.
Thinking about this more, I wonder if the update is intentional. If so, we need some coordination so that both apiserver and kublet don't try to delete.
Grace period 0 is intentional, but may not be required for correct behavior. If the user signals delete immediately, we record that intent so it shows up in watch and can be a signal kubelet to terminate immediately (although we don't actually do that today, so we could walk back the behavior). We definitely need a precondition delete on uid.
There will never be a single owner of pod lifecycle because pods are bound to nodes, and so all components have to deal with races to delete.
I chose to err on the side of being explicit about user intent with the update to zero out termination. But technically explicit deletion can be the same signal.
A delete operation will also trigger a watch event, so kubelet will be signaled even if we skip the update right? [edit] Oh I see you answered right before I asked.
It should be, yes. In the interest of fixing this test in the short term, I think the easiest thing to do might be to turn off the node controller for this section of the test. (Is it needed by anything in the test?)

But we should file at least two issues: "kubectl delete can race with graceful deletion"-- Things have to handle races, but there shouldn't be a race where you delete something and your delete fails because your own delete caused another component to issue a delete for the same thing... As far as I can see from the code, this could happen if apiserver context-switched at the wrong times (even if the more common thing of an old delete getting a new object is the issue at hand). controllers should delete via UID (or namespace/name + RV) -- I wouldn't be surprised if there's already an issue for this.
+1 to resourceVersion and uid preconditions on delete. Yes, maybe we shouldn't update the grace period before deletion in the case that the grace period is 0. Why can't we use unique pod names in the test? Turning off node controller seems like a bad idea. Index by uid is .
I don't see any flag option to turn of node controller. Pod's name is specified in the config file, is there any clean way to change the pod's name each time is called? Anyway, I'll try to make a PR to skip update if grace period is 0. That should alleviate this flake.
cc/ in case you are running into this issue.
As for how to change the name: we could use sed to replace the name. Or we could change the namespace.
This should be fixed by . I filed for deletion via UID or namespace/name+resourceVersion.
This happened again:
This error "] pods "redis-proxy" not found" here seems related to the error in .
I think the issue in is the same. The last few lines of logs: The symptom seems to align with my hypothesis in suggests the nodecontroller has successfully deleted a pod (probably "redis-master"), so kubectl fails with . I'll add more logs in nodecontroller to make sure this is the problem. In fact, we knew this race condition when investigating , but we discovered other race condition that are more likely to happen so we didn't solve this one.
Sent to show what pod nodecontroller has deleted.
Anywhere where we delete lists of pods (and other resources), including those filtered by label selector, we should ignore not-found errors. There are such loops in the controller reapers for cascading deletion. cc
makes safely ignore the NotFound error.

forces to issue a "GET" before submitting "DELETE". The "GET" will effectively check if the user is trying to delete a resource that is never created, so if later the API server sends a NotFound error in response to the "DELETE" request, kubectl can safely ignore it.


Question: A "Status" object SHOULD be returned by an API when an operation is not successful (when the server would return a non 2xx HTTP status code). The status object contains fields for humans and machine consumers of the API to determine failures. The information in the status object supplements, but does not override, the HTTP status code's meaning. <del> An "Operation" object MAY be returned by any non-GET API if the operation may take a significant amount of time. The name of the Operation may be used to retrieve the final result of an operation at a later time. </del> TODO: More details (refer to another doc for details) <del> TODO: Use SelfLink to retrieve operation instead. </del> Synthetic Resources -------------------

The schema understood by the Kubernetes configuration file is not described any where. The current practice mostly is copy/paste existing samples (for example ) and edit them. There is a need to define a comprehensive list of elements, and their documentation, so that other examples can leverage them.
Configuration files specify exactly our API objects. See:
This is exactly what I was looking for but not easily googlable, or documented clearly.
Could you please put a link to the swagger UI here?
The only mention in the public docs is here: which links directly to the struct definition on github. It appears that the Swagger docs have been deprecated, and I'm unable to find any documentation for the KubeletConfiguration resource kind in the new docs. It's referred to in at least one place, but is still not actually covered:


Question: update-generated-docs update-generated-swagger-docs update-openapi-spec <del> update-bazel" </del> <ins> update-bazel update-gofmt" </ins> for t in ${BASH_TARGETS}; do echo -e "${color_yellow}Running ${t}${color_norm}"

<!-- Please only use this template for submitting enhancement requests --What would you like to be : It will be more convenient to include when . Why is this needed: Now, contributor need to run and both. If including when , it will be more convenient. /sig contributor-experience /kind feature /assign


Question: func fakePortForwardServer(t *testing.T, testName string, serverSends, expectedFromClient map[uint16]string) http.HandlerFunc { return http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) { pf := &fakePortForwarder{ <ins> expected: expectedFromClient, </ins> received: make(map[uint16]string), send:     serverSends, }

I wanted to drop a note that I haven't forgotten about this issue. I have spent some time investigating and have yet to determine why some test runs result in the data not being forwarded correctly. I hope to resume digging into this soon, but I've got some planning tasks I need to complete first.
I have determined the root cause of this. In the test case, it: a port forwarding session, listening on a local port a TCP connection to the local port a goroutine copies data from the local port to the remote a goroutine copies data from the remote to the local port data to the TCP connection data from the TCP connection port forwarding, which results in the client streams being closed The problem is that the data written in step 3 is only to the local TCP port. There's no guarantee that the goroutine in 2.i copies the data to the remote before step 5 happens. In fact, if you reverse steps 3 () and 4 () so the write happens immediately before you close the stopChan, this test fails very quickly. I am thinking about how to fix this...
Not done yet:
Saw this again today:
- this was a different failure than this one. I've just opened for it and closing this one


Question: <ins> // +build windows /* Copyright 2020 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package kuberuntime import ( "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "github.com/stretchr/testify/assert" "testing" ) func TestVerifyRunAsNonRoot(t *testing.T) { pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ UID:       "12345678", Name:      "bar", Namespace: "new", }, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:            "foo", Image:           "windows", ImagePullPolicy: v1.PullIfNotPresent, Command:         []string{"testCommand"}, WorkingDir:      "testWorkingDir", }, }, }, } rootUser := "ContainerAdministrator" anyUser := "anyone" runAsNonRootTrue := true runAsNonRootFalse := false for _, test := range []struct { desc     string sc       *v1.SecurityContext uid      *int64 username string fail     bool }{ { desc:     "Pass if SecurityContext is not set", sc:       nil, username: rootUser, fail:     false, }, { desc: "Pass if RunAsNonRoot is not set", sc: &v1.SecurityContext{ RunAsNonRoot: nil, }, username: rootUser, fail:     false, }, { desc: "Pass if RunAsNonRoot is false (image user is root)", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootFalse, }, username: rootUser, fail:     false, }, { desc: "Pass if RunAsNonRoot is false (WindowsOptions RunAsUserName is root)", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootFalse, WindowsOptions: &v1.WindowsSecurityContextOptions{ RunAsUserName: &rootUser, }, }, username: rootUser, fail:     false, }, { desc: "Fail if container's RunAsUser is root and RunAsNonRoot is true", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootTrue, WindowsOptions: &v1.WindowsSecurityContextOptions{ RunAsUserName: &rootUser, }, }, username: rootUser, fail:     true, }, { desc: "Fail if image's user is root and RunAsNonRoot is true", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootTrue, }, username: rootUser, fail:     true, }, { desc: "Pass if image's user is non-root and RunAsNonRoot is true", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootTrue, }, username: anyUser, fail:     false, }, { desc: "Pass if container's user and image's user aren't set and RunAsNonRoot is true", sc: &v1.SecurityContext{ RunAsNonRoot: &runAsNonRootTrue, }, fail: false, }, } { pod.Spec.Containers[0].SecurityContext = test.sc err := verifyRunAsNonRoot(pod, &pod.Spec.Containers[0], test.uid, test.username) if test.fail { assert.Error(t, err, test.desc) } else { assert.NoError(t, err, test.desc) } } } </ins>

Hello, What happened: When we apply PodSecurityPolicy with rule: WIndows containers are still blocked instead we put: the pod is still blocked with logs: What you expected to happen: the Container should start How to reproduce it (as minimally and precisely as possible): Create Psp disableling Root Users: Create a pod Windows with runAsUserName: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.3 Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux 7 (Core) / windows server 2019 version 1809 Kernel (e.g. ): 3.10.0-514.10.2.el7.x86_64 Others: /sig windows
/sig windows
/assign I will test it and then post the test results
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


Question: } // IndexerFunc is a function that for a given object computes <del> // <value of an index> for a particular <index>. </del> <ins> // `<value of an index>` for a particular `<index>`. </ins> type IndexerFunc func(obj runtime.Object) string <del> // IndexerFuncs is a mapping from <index name> to function that // for a given object computes <value for that index>. </del> <ins> // IndexerFuncs is a mapping from `<index name>` to function that // for a given object computes `<value for that index>`. </ins> type IndexerFuncs map[string]IndexerFunc // Everything accepts all objects.


Question: testTries = 30 // Maximum number of pods in a test, to make test work in large clusters. maxNetProxyPodsCount = 10 <ins> // Number of checks to hit a given set of endpoints when enable session affinity. SessionAffinityChecks = 10 </ins> ) // NewNetworkingTestConfig creates and sets up a new test config helper.

Augment to turn on session affinity for a service, lookup the vip from a container/node and make sure we only hit a single endpoint with N ready/running endpoints.
This looks like it is still relevant can anyone confirm if we these? I still see a
/assign
Are you working on it? Could you please assign this issue to me and I am happy to fix it. Thanks a lot!
/assign I have it in my "backlog" behind NetworkPolicy stuff. Feel free to take it over if you have time.
GitHub didn't allow me to assign the following users: m1093782566. Note that only can be assigned. <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
Would appreciate :)
/assign


Question: } <ins> func TestGetDeviceRunContainerOptions(t *testing.T) { res1 := TestResource{ resourceName:     "domain1.com/resource1", resourceQuantity: *resource.NewQuantity(int64(2), resource.DecimalSI), devs:             checkpoint.DevicesPerNUMA{0: []string{"dev1", "dev2"}}, topology:         true, } res2 := TestResource{ resourceName:     "domain2.com/resource2", resourceQuantity: *resource.NewQuantity(int64(1), resource.DecimalSI), devs:             checkpoint.DevicesPerNUMA{0: []string{"dev3", "dev4"}}, topology:         false, } testResources := make([]TestResource, 2) testResources = append(testResources, res1) testResources = append(testResources, res2) podsStub := activePodsStub{ activePods: []*v1.Pod{}, } as := require.New(t) tmpDir, err := ioutil.TempDir("", "checkpoint") as.Nil(err) defer os.RemoveAll(tmpDir) testManager, err := getTestManager(tmpDir, podsStub.getActivePods, testResources) as.Nil(err) pod1 := makePod(v1.ResourceList{ v1.ResourceName(res1.resourceName): res1.resourceQuantity, v1.ResourceName(res2.resourceName): res2.resourceQuantity, }) pod2 := makePod(v1.ResourceList{ v1.ResourceName(res2.resourceName): res2.resourceQuantity, }) activePods := []*v1.Pod{pod1, pod2} podsStub.updateActivePods(activePods) err = testManager.Allocate(pod1, &pod1.Spec.Containers[0]) as.Nil(err) err = testManager.Allocate(pod2, &pod2.Spec.Containers[0]) as.Nil(err) // when pod is in activePods, GetDeviceRunContainerOptions should return runContainerOpts, err := testManager.GetDeviceRunContainerOptions(pod1, &pod1.Spec.Containers[0]) as.Nil(err) as.Equal(len(runContainerOpts.Devices), 3) as.Equal(len(runContainerOpts.Mounts), 2) as.Equal(len(runContainerOpts.Envs), 2) activePods = []*v1.Pod{pod2} podsStub.updateActivePods(activePods) testManager.UpdateAllocatedDevices() // when pod is removed from activePods,G etDeviceRunContainerOptions should return error runContainerOpts, err = testManager.GetDeviceRunContainerOptions(pod1, &pod1.Spec.Containers[0]) as.Nil(err) as.Nil(runContainerOpts) } </ins> func TestInitContainerDeviceAllocation(t *testing.T) { // Requesting to create a pod that requests resourceName1 in init containers and normal containers // should succeed with devices allocated to init containers reallocated to normal containers.

<!-- 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 --Pod worker panic when trying to re-allocating the device plugin resource during the node restart. The issue is potentially caused by an un-matching pod id. The map will be later used in an , which caused panic. ( func by itself is not thread-safe) Stack trace: DeviceManager Allocate() should be able to handle such race safely. Customer reported issue after upgrading to 1.18+. This is the new behavior introduced since 1.18+ from . Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node
/assign looking into the issue
I think your PR is related to this issue.
/unassign seems pretty relatable to PR cc
/triage accepted /priority critical-urgent
/remove-priority critical-urgent I don't think this is a release blocker at this point given the history reading through ; we can fix this in a cherry-pick.
Hi all, We are the GCP/GKE customer from which this issue originates. I can provide more information: it happened multiple times on our production cluster since we upgraded to 1.18 it happens in 2 scenarios: when GCP has a "host maintenance" event on our VMs with GPU (they don't support VM live migrations when GPU are involved), it forces a VM reboot: when multiple pods on that k8s node request a GPU prior to the reboot, we sometimes get the kubelet panic on node restart. when GKE upgrades our node-pools: new nodes (fresh VMs) get multiple scheduled pods requesting a GPU, sometimes leading to the kubelet panic. =this happens outside of our control The end result is a Pod scheduled on a node, but with no container ever created: our production workload is effectively broken until we manually delete the stuck pods. More details about our device usage: we use a of the each node has one GPU, and our device plugin declares N devices per real GPU; nvidia/cuda supports multi processing so it effectively shares the GPU among N pods/containers.

(our workload is memory-gpu bound, and uses <1/Nth of the gpu memory each, so no conflict) it worked great for almost 3 years now, with N=8
/cc
Now that we have confirmation that it occurs in live cluster I will take a closer look later this week.
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


Question: } func (kubemarkCluster *kubemarkCluster) getHollowNodeName() (string, error) { <del> nodes, err := kubemarkCluster.nodeLister.List(labels.Everything()) </del> <ins> selector, _ := labels.Parse(nodeGroupLabel) nodes, err := kubemarkCluster.nodeLister.List(selector) </ins> if err != nil { return "", err }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Kubemark controller should only use nodes for its template that are hollow nodes, rather than any node. Why is this needed: I want to perf-test the cluster autoscaler using clusters the contain real and hollow nodes. The original integration between cluster autoscaler and kubemark assumed multiple clusters, but I would like to enable using a single cluster for simplicity. I.e. a single node group with kubemark pods and many node groups of hollow kubemark nodes.
/sig node /sig autoscaling These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.
/remove-sig node /remove-sig autoscaling /sig scalability


Question: ########### <del> # Minions # </del> <ins> # Nodes # </ins> ########### if [[ "${version}" = "v1beta1" ]] || [[ "${version}" = "v1beta2" ]]; then <del> kube::log::status "Testing kubectl(${version}:minions)" </del> <ins> kube::log::status "Testing kubectl(${version}:nodes)" </ins> <del> kube::test::get_object_assert minions "{{range.items}}{{$id_field}}:{{end}}" '127.0.0.1:' </del> <ins> kube::test::get_object_assert nodes "{{range.items}}{{$id_field}}:{{end}}" '127.0.0.1:' </ins> <del> # TODO: I should be a MinionList instead of List kube::test::get_object_assert minions '{{.kind}}' 'List' </del> <ins> kube::test::get_object_assert nodes '{{.kind}}' 'List' </ins> <del> kube::test::describe_object_assert minions "127.0.0.1" "Name:" "Conditions:" "Addresses:" "Capacity:" "Pods:" </del> <ins> kube::test::describe_object_assert nodes "127.0.0.1" "Name:" "Conditions:" "Addresses:" "Capacity:" "Pods:" </ins> fi

kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

I know that you can get nodes / a node, but the help doesn't say you can or provide examples: To resolve this issue: the help for this command to include nodes (and any other resources we're missing). we generate the help text in a way that ensures this (and probably the many others that are drifting) don't get out of date? Or at least give us a heuristic as to whether this might be true, even if we have to fix it manually?
Can this be closed?
I'll close this one with ; we want to get rid of the minions (mi) resource name, since it doesn't work for v1beta3.


Question: attachment := makeTestAttachment(attachID, nodeName, pvName) attachment.Status.Attached = tc.initAttached attachment.Status.AttachError = tc.initAttachErr <del> csiAttacher.waitSleepTime = tc.sleepTime _, err := csiAttacher.k8s.StorageV1beta1().VolumeAttachments().Create(attachment) </del> <ins> _, err = csiAttacher.k8s.StorageV1beta1().VolumeAttachments().Create(attachment) </ins> if err != nil { t.Fatalf("failed to attach: %v", err) } <ins> trigerWatchEventTime := tc.trigerWatchEventTime finalAttached := tc.finalAttached finalAttachErr := tc.finalAttachErr </ins> // after timeout, fakeWatcher will be closed by csiAttacher.waitForVolumeAttachment if tc.trigerWatchEventTime > 0 && tc.trigerWatchEventTime < tc.timeout { go func() { <del> time.Sleep(tc.trigerWatchEventTime) attachment.Status.Attached = tc.finalAttached attachment.Status.AttachError = tc.finalAttachErr </del> <ins> time.Sleep(trigerWatchEventTime) attachment := makeTestAttachment(attachID, nodeName, pvName) attachment.Status.Attached = finalAttached attachment.Status.AttachError = finalAttachErr </ins> fakeWatcher.Modify(attachment) }() }

/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL


Question: }}, }, }, rest.ValidateAllObjectFunc, &metav1.CreateOptions{}) <del> svc := obj.(*api.Service) </del> if err != nil { t.Fatalf("Expected no error: %v", err) } <ins> svc := obj.(*api.Service) </ins> // Test dry run update request external name to node port updatedSvc, created, err := storage.Update(ctx, svc.Name, rest.DefaultUpdatedObjectInfo(&api.Service{

Which test(s) are flaking: TestServiceRegistryUpdateDryRun Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: the bug in the test that casts the return value even when the create fails: logging on slow etcd writes because of etcd-io/etcd a test binary for the affected package: the affected test using the tool: failures are seen, look at the logs to see the details about the error: /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
heh this, was a funny one, we had 1/2^8 chances of using a duplicate, with 1/2^16 I've got 2000 runs without any failures
/assign /remove-triage unresolved


Question: import ( "fmt" "reflect" <ins> "sort" </ins> "sync" "time"

Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)


Question: defaultObservationTimeout = time.Minute * 4 ) <del> var _ = framework.KubeDescribe("StartupProbe [Serial] [Disruptive] [NodeFeature:StartupProbe]", func() { f := framework.NewDefaultFramework("critical-pod-test") </del> <ins> var _ = framework.KubeDescribe("StartupProbe [Serial] [Disruptive] [NodeAlphaFeature:StartupProbe]", func() { f := framework.NewDefaultFramework("startup-probe-test") </ins> var podClient *framework.PodClient <ins> ginkgo.BeforeEach(func() { podClient = f.PodClient() }) </ins> /* These tests are located here as they require tempSetCurrentKubeletConfig to enable the feature gate for startupProbe.

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-serial Which test(s) are failing: StartupProbe [Serial] [Disruptive] [NodeFeature:StartupProbe] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
Tests are no longer running in CI, but tests are still failing. One failure is related to and another one is related to /reopen
Reopened this issue. <detailsIn response to : Tests are no longer running in CI, but tests are still failing. 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
Test failures can now be tracked in
/close It looks like this was solved around Nov 13-14, which is when merged
Closing this issue. <detailsIn response to : /close It looks like this was solved around Nov 13-14, which is when merged 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: .PHONY:	kbuild kpush <del> TAG = 1.12 </del> <ins> TAG = 1.13 </ins> # Rules for building the test image for deployment to Dockerhub with user kubernetes.

When I run Kubernetes cluster on GKE, it generates a lot of system logs coming from docker and kubelet. Even if my cluster runs just a few pods, I can see dozens or hundreds of log entries per second available in Google Cloud Logging in docker and kubelet logs. This makes the actual logs from my application get lost among them, if I do not set appropriate filter. Also, I am afraid that collecting massive amounts of logs imposes unnecessary workload on fluentd pod in my cluster. It would be good if I could just disable collection of kubelet/docker logs (and potentially other Kubernetes system logs) assuming that I do not want to have these logs exported.
/cc
since you tend to have a vested interest in node debug-ability, what's the minimum you'd want to have available here? From GKE's perspective, our users typically have no interest in these logs, so turning them off by default, even without an easy option to re-enable them, makes sense. Any user sophisticated enough to want them shouldn't have problems SSH'ing to the node for them. Is the story all that different in open-source kubernetes? Does anyone even care to have the kubelet and docker logs collected from the nodes? I've never used cloud logging to debug issues with them, it's always been easier to just SSH to the node. I'd lean towards not collecting them on the nodes in general. Also cc in case he has wisdom he'd like to impart
All I can say is that personally I have never accessed kubelet etc. logs "for real" when debugging -- as Alex says -- it is usually more direct just to SSH in. I would support not collecting these logs to improve cluster stability (but perhaps have a switch / technique to make it easy to collect them if the admin does care about this?).
One last call for to complain, because I'm starting on this now
Also
We want to avoid storing logs onto local disk in the future. In-order to achieve that, we need the existing cluster level logging infrastructure to work. Can the GKE problem be solved by moving system logs to a separate namespace? , Alex Robinson wrote:
How far in the future? Unless that's intended to happen soon, collecting the kubelet and docker logs in the meantime offers little value with a nontrivial resource (cpu+memory+egress) cost.

But yes, we can handle the system logs separately if we'd like. I think the most natural way would be to report them as compute engine logs, which could be done by adding an extra config option into the gcp output plugin.
, Alex Robinson wrote:
-- just to confirm, do you think this fix will be sufficient for you? In GKE, logs from containers will be listed under Container Engine, while logs from Docker and the Kubelet will be listed under Compute Engine, with the logs for each effectively being entirely seperated in the log viewer.
Yes, this will be sufficient in terms of not polluting Container Engine logs with system logs. I am still concerned about unnecessary load on fluentd caused by exporting Docker and Kubelet logs so ideally it would be great not to export these system logs if a user is not interested in them. But this is of slightly lower priority.
Hi, What's the status from this request? Is this available in 1.7.x or higher? Thanks.


Question: finalizer: []string{"kubernetes.io/valid-finalizer"}, }, { <ins> name:      "create-crd-with-fqdn-like-finalizer-without-path", finalizer: []string{"finalizer.without.valid-path.io"}, expectCreateWarnings: []string{ `metadata.finalizers: "finalizer.without.valid-path.io": prefer a domain-qualified finalizer name including a path (/) to avoid accidental conflicts with other finalizer writers`, }, }, { </ins> name:             "update-crd-with-invalid-finalizer", finalizer:        []string{"invalid-finalizer"}, updatedFinalizer: []string{"another-invalid-finalizer"},

k8s component developers are using FQDNs as finalizers (e.g. or which triggers an error message that isn't particularly easy for an end user to understand: To a naive end user, a fully qualified domain name is a pretty safe thing that is unlikely to conflict with anything else (as long as it's only used by someone from within the domain that owns it, which is a reasonable assumption). If the finalizer has s inside it but no , the message should suggest that finalizers need a . Something like: Do whatever it is that triggered the warning in (this is probably simpler than installing cert-manager and asking for a certificate) introduced: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig api-machinery
If thats ok I would like to work on that.
/assign
/triage accepted


Question: testRSScaleSubresources(f) }) <del> ginkgo.It("ReplicaSet Replace and Patch tests", func() { </del> <ins> /* Release: v1.21 Testname: ReplicaSet, is created, Replaced and Patched Description: Create a ReplicaSet (RS) with a single Pod. The Pod MUST be verified that it is running. The RS MUST scale to two replicas and verify the scale count The RS MUST be patched and verify that patch succeeded. */ framework.ConformanceIt("Replace and Patch tests", func() { </ins> testRSLifeCycle(f) }) })

[x] two weeks soak end date : 8 March 2021 According to this APIsnoop query, there are still some remaining Replicaset endpoints that are untested. with this query, you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested, stable, core endpoints replaceAppsV1NamespacedReplicaSet does not show up as untested as it touched by another not promoted to Conformance. Create a ReplicaSet with a static label Read the ReplicaSet info Scale the ReplicaSets to 2 Patch the ReplicaSet Read the ReplicaSet to ensure it is Patch Delete the Namespace and ReplicaSet Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent --------------------------------------|
createAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests patchAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests readAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests replaceAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests (4 rows) If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance /sig apps
/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: // UnmountWithForce unmounts given target but will retry unmounting with force option // after given timeout. func (mounter *Mounter) UnmountWithForce(target string, umountTimeout time.Duration) error { <del> err := tryUnmount(mounter, target, umountTimeout) </del> <ins> err := tryUnmount(target, mounter.withSafeNotMountedBehavior, umountTimeout) </ins> if err != nil { if err == context.DeadlineExceeded { klog.V(2).Infof("Timed out waiting for unmount of %s, trying with -f", target) <del> err = forceUmount(target) </del> <ins> err = forceUmount(target, mounter.withSafeNotMountedBehavior) </ins> } return err }

A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.


Question: tty           bool } <del> func extractPodAndContainer(cmd *cobra.Command, args []string, p *execParams) (podName string, containerName string, err error) { if len(p.podName) == 0 && len(args) == 0 { return "", "", cmdutil.UsageError(cmd, "POD is required for exec") </del> <ins> func extractPodAndContainer(cmd *cobra.Command, argsIn []string, p *execParams) (podName string, containerName string, args []string, err error) { if len(p.podName) == 0 && len(argsIn) == 0 { return "", "", nil, cmdutil.UsageError(cmd, "POD is required for exec") </ins> } if len(p.podName) != 0 { printDeprecationWarning("exec POD", "-p POD") podName = p.podName <del> if len(args) < 1 { return "", "", cmdutil.UsageError(cmd, "COMMAND is required for exec") </del> <ins> if len(argsIn) < 1 { return "", "", nil, cmdutil.UsageError(cmd, "COMMAND is required for exec") </ins> } <ins> args = argsIn </ins> } else { <del> podName = args[0] if len(args) < 2 { return "", "", cmdutil.UsageError(cmd, "COMMAND is required for exec") </del> <ins> podName = argsIn[0] args = argsIn[1:] if len(args) < 1 { return "", "", nil, cmdutil.UsageError(cmd, "COMMAND is required for exec") </ins> } } <del> return podName, p.containerName, nil </del> <ins> return podName, p.containerName, args, nil </ins> } <del> func RunExec(f *cmdutil.Factory, cmd *cobra.Command, cmdIn io.Reader, cmdOut, cmdErr io.Writer, p *execParams, args []string, re remoteExecutor) error { podName, containerName, err := extractPodAndContainer(cmd, args, p) </del> <ins> func RunExec(f *cmdutil.Factory, cmd *cobra.Command, cmdIn io.Reader, cmdOut, cmdErr io.Writer, p *execParams, argsIn []string, re remoteExecutor) error { podName, containerName, args, err := extractPodAndContainer(cmd, argsIn, p) </ins> namespace, err := f.DefaultNamespace() if err != nil { return err

When running , if you don't specify the deprecated and instead just do , it doesn't strip off the 1st command line arg, so sends the command to the container, whereas correctly sends just Regression from
FYI
We still support --, correct?
yes, we still support , but it's marked deprecated.
cc
has the fix. (and better unit test coverage) Sorry for the breakage!


Question: source $(dirname ${BASH_SOURCE})/${KUBE_CONFIG_FILE-"config-default.sh"} function detect-master () { <del> echo "KUBE_MASTER_IP: $KUBE_MASTER_IP" echo "KUBE_MASTER: $KUBE_MASTER" </del> <ins> echo "KUBE_MASTER_IP: $KUBE_MASTER_IP" echo "KUBE_MASTER: $KUBE_MASTER" </ins> } # Get minion IP addresses and store in KUBE_MINION_IP_ADDRESSES[] function detect-minions { <del> echo "Minions already detected" </del> <ins> echo "Minions already detected" </ins> } # Verify prereqs on host machine

Running vagrant from scratch gives the error: For vagrant cluster, the last minion cannot be detected. The /tmp/minions file only shows two minions, but after a while, using the same command, i.e. will get three minions. There is a race between kube-up and validate-, we should wait a while before panic.
I can look to fix this.


Question: func (obj *Unstructured) UnstructuredContent() map[string]interface{} { if obj.Object == nil { <del> obj.Object = make(map[string]interface{}) </del> <ins> return make(map[string]interface{}) </ins> } return obj.Object }

What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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: } func Test_ConstructVolumeSpec(t *testing.T) { <ins> if runtime.GOOS == "darwin" { t.Skipf("Test_ConstructVolumeSpec is not supported on GOOS=%s", runtime.GOOS) } </ins> fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ {Device: "/dev/sdb", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1"},

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit tests fail on osx. What you expected to happen: How to reproduce it (as minimally and precisely as possible): To see this unit test fail, you need to run go test on an osx machine. Environment: OS: macOS High Sierra v10.13.3
/sig storage /assign


Question: return false, nil }) if err != nil { <del> p, _ := f.ClientSet.CoreV1().Pods(testNamespaceName).Get(context.TODO(), testPodName, metav1.GetOptions{}) framework.Logf("Pod: %+v", p) </del> <ins> framework.Logf("failed to see event that pod is created: %v", err) </ins> } <del> framework.ExpectNoError(err, "failed to see Pod %v in namespace %v running", testPod.ObjectMeta.Name, testNamespaceName) </del> <ins> p, err := f.ClientSet.CoreV1().Pods(testNamespaceName).Get(context.TODO(), testPodName, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to get Pod %v in namespace %v", testPodName, testNamespaceName) framework.ExpectEqual(p.Status.Phase, v1.PodRunning, "failed to see Pod %v in namespace %v running", p.ObjectMeta.Name, testNamespaceName) </ins> ginkgo.By("patching the Pod with a new Label and updated data") podPatch, err := json.Marshal(v1.Pod{

pull-kubernetes-conformance-kind-ga-only-parallel [sig-node] Pods should run through the lifecycle of Pods and PodStatus [Conformance] After is merged. It relies on events which are not reliable as discussed . No response /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The test is not failing that much looking at the testgrid. Is it actually an issue?
Not so often, but it does happen. So, I think that it is worth fixing.
still flaking -
flaking conformance tests are concerning and should take priority over new conformance test additions
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 I still see this test failing , also in periodic jobs
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 seems like it's is still failing
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]:
still flake /remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/assign Namanl2001
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
please unassign if you are not working on it. Seems to be still flaking
It still flakes but not that much. I checked the history: adjusted the timeout from 30s to 1m. changed it not to fail for watching Delete Event, and just print it like below: This time, we see the above adding warning and then failed. Looking into kubelet/container runtime log. The pod is just deleted after 1 min, maybe 1min10s. I'm afraid that we have to adjust the timeout of the delete pod again to fix it. Is a valid pod deletion timeout?

I think most deletion timeout of pod is 5min, however this is too long after pod with .
but why it takes so long kubelet to delete a pod? what are all of those ""Failed to delete cgroup paths" messages? can this be hiding some problem with runc or the kubelet?
Sep 19 13:14:56 kinder-external-etcd-worker-2 kubelet[359]: E0919 13:14:56. 359 ] "Error syncing pod, skipping" err="failed to delete cgroup paths for [kubepods besteffort pod53d19839-496a-4be8-8964-] : unable to destroy cgroup paths for cgroup [kubepods besteffort pod53d19839-496a-4be8-8964-] : Timed out while waiting for systemd to remove kubepods-besteffort-" pod="pods-900/pod-test" podUID=-496a-4be8-8964- Sep 19 13:14:56 kinder-external-etcd-worker-2 kubelet[359]: I0919 13:14:56. 359 ] "Failed to delete cgroup paths" cgroupName=[kubepods besteffort pod53d19839-496a-4be8-8964-] err="unable to destroy cgroup paths for cgroup [kubepods besteffort pod53d19839-496a-4be8-8964-] : Timed out while waiting for systemd to remove kubepods-besteffort-" Sep 19 13:14:56 kinder-external-etcd-worker-2 containerd[220]: time="2023-09-19T13:14:56.925525892Z" level=info msg="StartContainer for "e3b435116d2640d7c8166332e1c4bf6722f97ac1401035cbe443704c8b442efd" returns successfully" Sep 19 13:14:56 kinder-external-etcd-worker-2 kubelet[359]: I0919 13:14:56.

359 ] "Failed to delete cgroup paths" cgroupName=[kubepods besteffort pod53d19839-496a-4be8-8964-] err="unable to destroy cgroup paths for cgroup [kubepods besteffort pod53d19839-496a-4be8-8964-] : Timed out while waiting for systemd to remove kubepods-besteffort-" Sep 19 13:15:01 kinder-external-etcd-worker-2 kubelet[359]: I0919 13:15:01. 359 ] "Cleaned up orphaned pod volumes dir" podUID=-496a-4be8-8964- path="/var/lib/kubelet/pods/-496a-4be8-8964-/volumes" It means timeout. Another failure is not for the same reason.
/joke
I wish I could clean mirrors for a living. It's just something I can see myself doing. <detailsIn response to : /joke Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This is starting to be worrisome
another failure
was another occurrence of this I think. I'm seeing the timeout error for deleting the pod in the build logs: And then the error: It has the same sanbok not found error in the kind-worker logs: Along with the same cgroup error in the logs: So it's probably an instance of the first case mentioned caused by timeout.
Flake in . Delete timeout is 1 minute here. It still need more investigation why this is not deleted in 1 min.(heavy load or logic problems.)
Flake twice in yersterday.


Question: package vsphere import ( <del> "fmt" </del> "io/ioutil" <del> "strings" </del> ) <del> const ( UUIDPath   = "/sys/class/dmi/id/product_serial" UUIDPrefix = "VMware-" ) </del> <ins> const UUIDPath = "/sys/class/dmi/id/product_serial" </ins> <del> func GetVMUUID() (string, error) { </del> <ins> func getRawUUID() (string, error) { </ins> id, err := ioutil.ReadFile(UUIDPath) if err != nil { <del> return "", fmt.Errorf("error retrieving vm uuid: %s", err) } uuidFromFile := string(id[:]) //strip leading and trailing white space and new line char uuid := strings.TrimSpace(uuidFromFile) // check the uuid starts with "VMware-" if !strings.HasPrefix(uuid, UUIDPrefix) { return "", fmt.Errorf("Failed to match Prefix, UUID read from the file is %v", uuidFromFile) } // Strip the prefix and white spaces and - uuid = strings.Replace(uuid[len(UUIDPrefix):(len(uuid))], " ", "", -1) uuid = strings.Replace(uuid, "-", "", -1) if len(uuid) != 32 { return "", fmt.Errorf("Length check failed, UUID read from the file is %v", uuidFromFile) </del> <ins> return "", err </ins> } <del> // need to add dashes, e.g. "564d395e-d807-e18a-cb25-b79f65eb2b9f" uuid = fmt.Sprintf("%s-%s-%s-%s-%s", uuid[0:8], uuid[8:12], uuid[12:16], uuid[16:20], uuid[20:32]) return uuid, nil </del> <ins> return string(id), nil </ins> }

<!-- 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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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


Question: // We're sending new job to see if it reaches syncHandler. testJob.Name = "foo" fakeWatch.Add(&testJob) <del> select { case <-received: case <-time.After(controllerTimeout): t.Errorf("Expected 1 call but got 0") } </del> <ins> t.Log("Waiting for job to reach syncHandler") <-received } </ins> <del> // We're sending fake finished job, to see if it reaches syncHandler - it should not, // since we're filtering out finished jobs. testJobv2 := experimental.Job{ ObjectMeta: api.ObjectMeta{Name: "foo"}, </del> <ins> func TestIsJobFinished(t *testing.T) { job := &experimental.Job{ </ins> Status: experimental.JobStatus{ Conditions: []experimental.JobCondition{{ <del> Type:               experimental.JobComplete, Status:             api.ConditionTrue, LastProbeTime:      unversioned.Now(), LastTransitionTime: unversioned.Now(), </del> <ins> Type:   experimental.JobComplete, Status: api.ConditionTrue, </ins> }}, }, } <del> fakeWatch.Modify(&testJobv2) select { case <-received: t.Errorf("Expected 0 call but got 1") case <-time.After(controllerTimeout): </del> <ins> if !isJobFinished(job) { t.Error("Job was expected to be finished") } job.Status.Conditions[0].Status = api.ConditionFalse if isJobFinished(job) { t.Error("Job was not expected to be finished") } job.Status.Conditions[0].Status = api.ConditionUnknown if isJobFinished(job) { t.Error("Job was not expected to be finished") </ins> } }

Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.


Question: type PersistentVolume struct { TypeMeta   `json:",inline"` <del> ObjectMeta `json:"metadata,omitempty"` </del> <ins> ObjectMeta `json:"metadata,omitempty" description:"standard object metadata; see http://docs.k8s.io/api-conventions.md#metadata"` </ins> //Spec defines a persistent volume owned by the cluster Spec PersistentVolumeSpec `json:"spec,omitempty" description:"specification of a persistent volume as provisioned by an administrator"`

PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?


Question: } } <del> if instanceType, err := getInstanceTypeByProviderIDOrName(ctx, instances, node); err != nil { </del> <ins> if instanceType, err := getInstanceTypeByProviderIDOrName(ctx, instances, providerID, node.Name); err != nil { </ins> return nil, err } else if instanceType != "" { klog.V(2).Infof("Adding node label from cloud provider: %s=%s", v1.LabelInstanceType, instanceType)

<!-- 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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /kind regression
/cc
can we open a new issue re:


Question: # if there are no files vendored under this package... if [[ -z "$(find "${DEPS_DIR}/${PACKAGE}" -mindepth 1 -maxdepth 1 -type f)" ]]; then <del> # and we have the same number of submodules as subdirectories... if [[ "$(find "${DEPS_DIR}/${PACKAGE}/" -mindepth 1 -maxdepth 1 -type d | wc -l)" -eq "$(echo "${modules}" | grep -cE "^${PACKAGE}/")" ]]; then </del> <ins> # and we have at least the same number of submodules as subdirectories... if [[ "$(find "${DEPS_DIR}/${PACKAGE}/" -mindepth 1 -maxdepth 1 -type d | wc -l)" -le "$(echo "${modules}" | grep -cE "^${PACKAGE}/")" ]]; then </ins> echo "Only submodules of ${PACKAGE} are vendored, skipping" >&2 continue fi

When updating go-oidc, running failed when looking for licenses; specifically, it was looking for ’s file, but that was no longer vendored. Since no packages are actually used, the license shouldn’t be needed. On master, No response Tip of the master branch. N/A N/A N/A N/A N/A
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 k8s-infra /cc


Question: // This client will attempt a one-shot connection, then die, without restarting the pod. // Test can then be asserted based on whether the pod quit with an error or not. func createNetworkClientPod(f *framework.Framework, namespace *v1.Namespace, podName string, targetService *v1.Service, targetPort int) *v1.Pod { <ins> return createNetworkClientPodWithRestartPolicy(f, namespace, podName, targetService, targetPort, v1.RestartPolicyNever) } // Create a client pod which will attempt a netcat to the provided service, on the specified port. // It is similar to createNetworkClientPod but supports specifying RestartPolicy. func createNetworkClientPodWithRestartPolicy(f *framework.Framework, namespace *v1.Namespace, podName string, targetService *v1.Service, targetPort int, restartPolicy v1.RestartPolicy) *v1.Pod { </ins> pod, err := f.ClientSet.CoreV1().Pods(namespace.Name).Create(context.TODO(), &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ GenerateName: podName + "-",

<!-- 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: The NetworkPolicy e2e test fails regardless of which CNI plugin is enabled. The test assumes the client Pod can recheck connectivity after updating its label, but the client won't restart after the first failure, so the second check will always fail. What you expected to happen: The test should succeed if a CNI plugin implements NetworkPolicy correctly. How to reproduce it (as minimally and precisely as possible): a CNI that supports NetworkPolicy. the e2e test by focusing "should allow ingress access from updated pod". test will always fail. Anything else we need to know?: Environment: Kubernetes version (use ): 16.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing /assign
/remove-sig testing /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved
I see this in Calico 3.10 as well confirming that its definitely an issue.


Question: "strings" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake"

make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
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
see example successful run:
For reference -
fix in
screaming


Question: ) const ( <del> criticalPodName   = "critical-pod" guaranteedPodName = "guaranteed" burstablePodName  = "burstable" bestEffortPodName = "best-effort" </del> <ins> criticalPodName            = "critical-pod" guaranteedPodName          = "guaranteed" burstablePodName           = "burstable" bestEffortPodName          = "best-effort" systemCriticalPriorityName = "critical-pod-test-high-priority" </ins> ) var _ = framework.KubeDescribe("CriticalPod [Serial] [Disruptive] [NodeFeature:CriticalPod]", func() { f := framework.NewDefaultFramework("critical-pod-test") ginkgo.Context("when we need to admit a critical pod", func() { tempSetCurrentKubeletConfig(f, func(initialConfig *kubeletconfig.KubeletConfiguration) { if initialConfig.FeatureGates == nil {

<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18


Question: "http://metadata.google.internal/0.2/", "http://metadata.google.internal/computeMetadata/v2/", // kube-env. <del> "http://metadata.google.internal/0.1/meta-data/attributes/kube-env", "http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/kube-env", </del> "http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env", // VM identity. <del> "http://metadata.google.internal/0.1/meta-data/service-accounts/default/identity", "http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/identity", </del> "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity", // Forbidden recursive queries. "http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true",

Warning: The v0.1 and v1beta1 metadata server endpoints are deprecated and scheduled for shutdown on September 30, 2020. This test (which runs in most e2e jobs that run on GCE): Schedules a container that runs this: Resulting in a number of legacy metadata endpoints getting hit. To see if this test is going to start failing across all release branches on Sep 30th, we could try disabling the endpoints ahead of time via: In fact and support for expecting different results based on whether is set. My concern is the test expects 200 for some root endpoints, and 403 for disabled endpoints. However the e-mail I received as a GCP customer tells me any legacy endpoints may return 404. I'm inclined to suggest we remove the legacy endpoints from the check, bump the image version, and cherry-pick use of the new image version back to all release-branches. WDYT since you were involved with the earlier PRs /sig auth /sig cloud-provider /provider gcp /sig testing /priority important-soon (I'm tempted to critical-urgent this but it's not drop-everything yet) /milestone v1.20
/kind cleanup
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
Bug Triage here, we're pretty late into code freeze and it doesn't look like there has been much activity recently. I am going to clear the milestone on this issue. /milestone clear
any update here?
Try to cleanup the legacy endpoints in
/milestone v1.21
/reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: )
Reopened this issue. <detailsIn response to : /reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: ) 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 /assign


Question: dockerExecHandler dockertools.ExecHandler, resolverConfig string, cpuCFSQuota bool, <del> daemonEndpoints *api.NodeDaemonEndpoints) (*Kubelet, error) { </del> <ins> daemonEndpoints *api.NodeDaemonEndpoints, oomAdjuster *oom.OOMAdjuster) (*Kubelet, error) { </ins> if rootDirectory == "" { return nil, fmt.Errorf("invalid root directory %q", rootDirectory) }

The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign See PR for docs at Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
~This would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.


Question: networkError             error internalError            error cidr                     string <del> initError                error </del> healthChecks             []*healthCheck }

In our k8s cluster, a node's status is NotReady, and we checked the kubelet's log, that repeated "skipping pod synchronization" every 5 minutes: I found the code where printing those logs, in the syscLoop function. if runtimeState has error, kubelet will get into endless loop, and will print "skipping pod synchronization" every five minutes. In our case, the node got an error when startup, in the function initializeModules, which called our cloud provider to get node info, because the call returned an error, kubelet set the error to runtimeState, and ran syscLoop next, going to endless loop. I think there is a problem here: Startup function "initializeModules" encountered an error like "failed get node info", which is rarely, kubelet should exit its process and it will be restarted by systemd successfully. Restarting kubelet is more reaonable than printing error log in the endless loop, Restarting event can be mornitored easily, but the admin can hardly detect the endless loop.
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. Prevent issues from auto-closing with an comment. 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
/remove-lifecycle rotten


Question: // ControlPlaneComponent holds settings common to control plane component of the cluster type ControlPlaneComponent struct { // ExtraArgs is an extra set of flags to pass to the control plane component. <ins> // A key in this map is the flag name as it appears on the // command line except without leading dash(es). </ins> // TODO: This is temporary and ideally we would like to switch all components to // use ComponentConfig + ConfigMaps. ExtraArgs map[string]string `json:"extraArgs,omitempty"`

<!-- 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 --I was reading the doc about NodeRegistration, with an interest in specifying some . I noticed that the doc (e.g., ) does not tell me exactly how to identify each arg: exactly as on the command line (including leading dash(es)), as on the command line but without leading dash(es), or camelCase. I expected the doc to enable me to write some with confidence. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 cluster-lifecycle
FWIW the answer is flag names as on the command name but without any leading dashes. This also applies to controllerManager.extraArgs, scheduler.extraArgs, etc. which hopefully should all cover this similarly (if not now, after fixing ...)

<!-- 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 --I was reading about how to use kubeadm and noticed a typo in the API documentation. speaks of the "node subnet" where I think "pod subnet" is intended. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 cluster-lifecycle
/area kubeadm