Question: "testing" "time" <ins> "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/apimachinery/pkg/util/wait" genericapirequest "k8s.io/apiserver/pkg/endpoints/request"

When continuously re-applying the same object via a controller or kubectl with SSA the resourceVersion increases every time. I expected the resourceVersion to stay the same if the client always sends the same object via SSA, especially if the resulting object doesn't change (apart from resourceVersion & managedFields, but these are managed by the apiserver). Apply this CRD: <details</summary</detailsApply this CR: <details</summary</detailsGet state of the CR after first apply Apply the CR again Get state of the CR after second apply Diff =The resourceVersion and the "time" field of the managedField entry of the "test-manager" increases. The use case we have is a lot more complex than this simple scenario. The tl;dr is that we want to implement caching for our SSA calls, so that we don't have SSA calls on every reconcile of our controller if nothing actually changes. This is relatively hard to do if the resourceVersion increases after every apply. I took a closer look at the APIserver and ~ the following happens: "incoming" SSA patch is applied over the live object from etcd this leads to a change because has which means the field will be dropped Because of that change the "time" field in the managedField entry gets set to "time.Now()" later during admission the namespace field gets defaulted again (I also tried this with a mutating webhook, same result) On a high-level: client always applies the same object defaulting always results in the same object resourceVersion and managedFields[].time continuously go up I think there are many similar cases that would lead to this behavior. Basically whenever the admission chain mutates a field previously set via SSA. Notes: This only happens if there is 1s between each apply, otherwise the managedField[].time is identical and then the resourceVersion stays the same (because we then don't write to etcd) <detailsI also tried this with client-go v0.30 and kube-apiserver v1.30. Same result. </details<detailsRunning this natively on Apple Silicon M2. But can't imagine this makes a difference. Also got the same results in Docker Desktop on Mac. </details
(cc might be interesting for you)
/sig api-machinery
It looks less a bug but more of a intended behavior to me.

/cc /triage accepted
Bypassing the writes triggered by noop applies would break storage version migration (), so we're committed to supporting this behavior as a feature.
I am confused. Are you saying this is intended behavior for a NOP SSA apply to increment resourceVersion? This seems to not actually happen in all cases, only for certain objects/edge cases (see ). For example, try this: No resourceVersion is incremented above). Surprisingly I couldn't find any clear statement that SSA doesn't increment the resource version, but does say "a no-op apply is not very much more work for the API server than an extra GET" which seems impossible if resourceVersion is incremented
is probably only updating it because either the fieldManager changes or in the patch body the apiVersion is different (or both, perhaps)?
We need this in storage version migration to make sure we correctly handles the CRD schema changes. See Joe's comments here - If it helps to understand this better, we have tests to validate this.
I may have misspoke. When storage versions changes, a NOP SSA apply will trigger a resourceVersion bump. If the storage version is unchanged and an update would be a NOP for etcd, I believe we short-circuit the write (?). This might explain the configMap case.
For the reported issue: We've seen cases like this before where the time gets bumped causing a NOP to become a write. This could be improved. Note that this isn't technically a bug because the API server is allowed to bump the resourceVersion for any write (the discussion about storage version changes causing this is a good example of where this can happen in a way that the caller wouldn't expect). But I'd like to see the etcd write optimized away for cases like this.
Sounds similar to perhaps which had some investigation. FWIW as a controller author my expectation is that repeatedly applying does not repeatedly trigger resourceVersion increments. It's fine if it happens rarely (storage version change, etc) but if it happens consistently that means our own writes re-trigger reconciliation and we have an infinite loop of writes. AFAIK all the marketing around writing SSA controllers has been that you just apply what you want and don't try to do a get+diff+apply. Even if we did want to do that, it doesn't really work well currently ().

If we aren't able to rely on NOP writes (usually) being NOPs, I don't see how we are supposed to use SSA to write a controller at all?
This is a really good point. I agree.
looks like it was intended fix this sort of problem. I'm looking into why it doesn't work for this case.
doesn't work for CRs since the managed fields are inside of a unstructured object and are not typed as (for the slow path equality check in IgnoreManagedFieldsTimestampsTransformer).
is a draft proposal for a fix. Feedback welcome on how to make this fix cleaner. I'll test carefully before moving it out of draft.


Question: ) const ( <del> // renewInterval is the interval at which the lease is renewed renewInterval = 10 * time.Second </del> <ins> // defaultRenewInterval is the default interval at which the lease is renewed defaultRenewInterval = 10 * time.Second </ins> // maxUpdateRetries is the number of immediate, successive retries the Kubelet will attempt // when renewing the lease before it waits for the renewal interval before trying again, // similar to what we do for node status retries

What happened: The node lease feature becomes beta and enables by default in v1.14. After upgrading our cluster to v1.14, we found some nodes become not ready occasionally and later become ready again after a few seconds. In order to have a quick failure detection and recovery, our kubelet has a flag setting and controller-manager has another flag setting . If we use node lease feature, the kubelet doesn't report it's status as frequently as specified by flag , and use node lease mechanism to report that node is alive. the default interval at which node lease renew is hardcoded 10s, but it can't be exactly 10s and may be a little bit more than 10s because of some network latency. when controller-manager doesn't receive messages from kubelet in every 10s in our case, it will mark this node as unreachable and not ready state, but in the next reconcile cycle, it receives the lease update message and mark this node as reachable again, so the node status is flapping between ready and not ready state. This seems a breaking change that setting kubelet's lease renewing interval to a hardcoded 10s, even though our node status update frequency has a little bit small value, node lease should align kubelet's previous behavior and renew as frequently as to reporting alive message, otherwise controller-manager will mark this node as unreachable. What you expected to happen: So we should not merely set node lease renewing interval to 10s, maybe depending on the has a more heuristic value. How to reproduce it (as minimally and precisely as possible): a v1.14 kubernetes cluster set flag to kubelet and to controller-manager. wait a few minute, 'll find some log regarding in controller-manager's log. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig node /kind bug /assign
smells like a regression WDYT?
cc
- not a regression - I think the only issue is that we may be missing some documentation, but other than that I think everything looks fine.

So how it works now is: There are two fields in Kubelet Config: (a) NodeStatusUpdateFrequency: (b) NodeStatusReportFrequency The comments there are pretty detailed and you should read them, but in short the first one roughly translates to how frequenty the lease object is send and the second how frequenty node status is updated (assuming nothing changed in the meantime). IIRC, there was a decision to not expose it via a flag, because flags in kubelet are deprecated and we're moving to config. So you can actually mitigate the problem by setting the second field in the config I mentioned above to some smaller value (like 5s) and then you will get Node Status updates every 5s as you want. So it's possible to achieve what you want without any code changes. That said, enabling for changing the default lease duration to something larger than 10s, sounds reasonable.
How about making the default lease duration 12s (or 14s) ? I can send out a PR once a new default is agreed upon.
thanks for comments. But what if we both want node lease feature enables (as this is an indeed helpful feature) and heartbeat with apiserver within some smaller interval (like 5s) via node lease mechanism?
IMHO, we should add a filed in Kubelet Config to let user tune the node lease renewing interval, WDYT?
That sounds like the cleanest option to me (rather than some playing with existing params). - who is the owner of the feature on Node side.


Question: t.Errorf("expected to be %s", metav1.StatusReasonMethodNotAllowed) } <ins> if !IsAlreadyExists(NewGenerateNameConflict(resource("tests"), "3", 1)) { t.Errorf("expected to be %s", metav1.StatusReasonAlreadyExists) } if time, ok := SuggestsClientDelay(NewGenerateNameConflict(resource("tests"), "3", 1)); time != 1 || !ok { t.Errorf("unexpected %d", time) } </ins> if time, ok := SuggestsClientDelay(NewServerTimeout(resource("tests"), "doing something", 10)); time != 10 || !ok { t.Errorf("unexpected %d", time) }

Spawned from is converting an AlreadyExists error into a server timeout error if it has a generateName That means that this returns really confusing errors:
/cc
- a simple if for the objectMeta.Name seems to do the trick... is this enough? or were you looking for better way instead of NewServerTimeoutForKind ?
if no name was provided originally, the alreadyexists error occurs after the name field is populated with a generated name, so returning in that case makes this entire function a no-op in every case I can find. I just think inferring a ServerTimeout error from an AlreadyExists error and the presence of GenerateName is really odd
This needs to be triaged as a release-blocker or not for 1.5
Not a blocker
thanks
Is it appropriate to move this to the next milestone or clear the 1.5 milestone? (and remove the non-release-blocker tag as well)
Issues go stale after 30d 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
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
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
Should we return another instead of to include the generate name information ?
seems like the correct error in other cases involving an object that already exists with that name.
Looks like is not active due to age. If anyone is interested, please feel free to work on this! Like mentioned in , a unit test along with the required changes would be good to add.
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
Would be really helpful if solved :) /remove-lifecycle rotten
I am new to Kubernetes community and was going through role board recommendations on older threads - If everyone is ok, can I pick this issue and work on it.
It seems already created PR for this issue - It doesn't seem to have merged. - Let me know if you are still working, else I can take a stab (Though most of the work is already done by you) to further drive this.
I'm not working on it. Please take it forward. Thanks
Thanks for the confirmation. I will work on this.
I have taken a look at the complete flow of the issue. From what I understand, there are a couple of choices Option - (1) Validate in function if an object has both name and generateName and fail the request if that is the case. Option - (2) in , set generateName to empty if it also has a name. This will make sure that the error in CheckGeneratedNameError is (when the generated name is conflicting with the already existing name of some other object). This is essentially the approach took in this , which no longer is actively worked on. /cc
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
/lifecycle frozen
/needs-triage It's kind of embarrassing that this is still open.
(I think the fix may be to delete the mentioned function entirely-- why would we describe this situation as a timeout error?)
do you know someone who's interested working on this? We will come back on this issue in the next triage meeting.
/help
/triage accepted
The origin of :


Question: # github.com/containerd/go-runc => github.com/containerd/go-runc v0.0.0-20180907222934-5a6d9f37cfa3 # github.com/containerd/ttrpc => github.com/containerd/ttrpc v1.0.2 # github.com/containerd/typeurl => github.com/containerd/typeurl v1.0.1 <del> # github.com/containernetworking/cni => github.com/containernetworking/cni v0.8.0 </del> <ins> # github.com/containernetworking/cni => github.com/containernetworking/cni v0.8.1 </ins> # github.com/coredns/corefile-migration => github.com/coredns/corefile-migration v1.0.11 # github.com/coreos/bbolt => github.com/coreos/bbolt v1.3.2 # github.com/coreos/etcd => github.com/coreos/etcd v3.3.13+incompatible

is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: {p1: unscheduled5Hours, p2: unscheduled8Hours}, {p1: ready5Hours, p2: ready10Hours}, } <del> for _, tc := range equalityTests { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.LogarithmicScaleDown, !tc.disableLogarithmicScaleDown)() if tc.p2 == nil { tc.p2 = tc.p1 } podsWithRanks := ActivePodsWithRanks{ Pods: []*v1.Pod{tc.p1, tc.p2}, Rank: []int{1, 1}, Now:  now, } if podsWithRanks.Less(0, 1) || podsWithRanks.Less(1, 0) { t.Errorf("expected pod %q to be equivalent to %q", tc.p1.Name, tc.p2.Name) } </del> <ins> for i, test := range equalityTests { t.Run(fmt.Sprintf("Equality tests %d", i), func(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.LogarithmicScaleDown, !test.disableLogarithmicScaleDown)() if test.p2 == nil { test.p2 = test.p1 } podsWithRanks := ActivePodsWithRanks{ Pods: []*v1.Pod{test.p1, test.p2}, Rank: []int{1, 1}, Now:  now, } if podsWithRanks.Less(0, 1) || podsWithRanks.Less(1, 0) { t.Errorf("expected pod %q to be equivalent to %q", test.p1.Name, test.p2.Name) } }) </ins> } type podWithRank struct { pod  *v1.Pod rank int

During implementation of KEP 3393 (PodReplacementPolicy for Jobs) we found that the unit tests of do not follow common patterns established in k/k. 1) The tests are not written using table driven design (). 2) The tests use rather than . This probably should be done as two separate PRs but wanted to highlight some areas that could use some cleanup. Not using means that we don't see diffs in the unit tests that makes this difficult. And not using table driven tests makes it difficult to add new test cases as it usually is brought up during review that we should use a table-driven test but the entire file does not obey this format.
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 apps /kind cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig apps /kind cleanup /help /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'd like to work on it /assign
I'd also like to make some contributions. /assign
Looks like this need two PRs. tests are not written using table driven design (). tests use Differences rather than Cmp.Diff. I think I can work on the 2nd one and leave the 1st one to you.

Sounds good?
By looking through the , I found the main function to comapre the results have already used cmp.Diff. Can you elaborate more on which part you expect to use cmp.Diff? func verifyDeletedAndPatchedPods(t testing.T, client fake.Clientset, wantDeletedPodNames, wantPatchedPodNames sets.String) { t.Helper() deletedPodNames := getDeletedPodNames(client) if diff := cmp.Diff(wantDeletedPodNames, deletedPodNames); diff != "" { t.Errorf("Deleted pod names (-want,+got):n%s", diff) } patchedPodNames := getPatchedPodNames(client) if diff := cmp.Diff(wantPatchedPodNames, patchedPodNames); diff != "" { t.Errorf("Patched pod names (-want,+got):n%s", diff) } }
I am really sorry about this. Too much multitasking!! I meant not
Hey ! Sorry, I didn't see this before. No problem at all, but consider that one change depends on the other, and since my task implies a big refactor, there might be conflicts when merging your PR... That's why I see two possible scenarios happening: Your PR gets merged before I raise mine: Then fine, I'll rebase your changes and adapt my code Mine is ready before yours is merged: In this case, I propose you commit your changes to my PR. Both of us will appear as coauthors of the change Getting a PR merged in the Kubernetes project takes quite some time (trust me, I talk by experience and can confirm ) WDYT?
Let's see how it goes. We can always rebase the code change to adapt new.
btw, did you already begin to work on task 1? If not, I may just go ahead and work on it right away since I have already dig into it.
yes, I already started And If you ask me, better to keep it this way so we both have an opportunity to have a contribution
cool. Sounds good.
/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
Hi if this issue needs to be worked on any further, please assign me for the same.
has a PR up that will solve the second part of this issue.


Question: setInitCommand(input.pod, fmt.Sprintf("ln -s /bin %s", input.subPathDir)) // Pod should fail <del> testPodFailSubpath(input.f, input.pod) </del> <ins> testPodFailSubpath(input.f, input.pod, false) </ins> }) It("should fail if subpath file is outside the volume [Slow]", func() {

<!-- 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!--What happened: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!


Question: package builder import ( <del> "k8s.io/klog/v2" </del> <ins> "fmt" "strings" </ins> "k8s.io/kube-openapi/pkg/aggregator" "k8s.io/kube-openapi/pkg/spec3" "k8s.io/kube-openapi/pkg/validation/spec" ) <ins> const metadataGV = "io.k8s.apimachinery.pkg.apis.meta.v1" const autoscalingGV = "io.k8s.api.autoscaling.v1" </ins> // MergeSpecs aggregates all OpenAPI specs, reusing the metadata of the first, static spec as the basis. // The static spec has the highest priority, and its paths and definitions won't get overlapped by // user-defined CRDs. None of the input is mutated, but input and output share data structures.

Related to Seeing the following errors in kube-apiserver logs when CRDs are applied: No errors in logs Apply any CRD manifest No response <details</details<details</details<details</details<detailsRancher RKE2 </details<detailscontainerd 1.6.4 </details<detailscanal </details
/sig api-machinery
/assign
Did this cause any specific trouble to your cluster I'm curious what the impact/severity of this is.
Everything seems to work fine, but there's a bunch of log spew every time a CRD manifest is loaded. In K3s we mix all the control-plane component logs together in a single pair of stdout/stderr streams so it's quite noisy, compared to previous releases. The fact that these come out at WARN level with a scary prefix makes them look pretty serious, and I expect we will get a fair bit of users asking about it once we release.
/triage accepted


Question: } tests := []struct { <del> description   string node          *corev1.Node expected      *corev1.Node pods          []corev1.Pod rcs           []corev1.ReplicationController replicaSets   []appsv1.ReplicaSet args          []string expectWarning string expectFatal   bool expectDelete  bool </del> <ins> description                string node                       *corev1.Node expected                   *corev1.Node pods                       []corev1.Pod rcs                        []corev1.ReplicationController replicaSets                []appsv1.ReplicaSet args                       []string failUponEvictionOrDeletion bool expectWarning              string expectFatal                bool expectDelete               bool </ins> }{ { description:  "RC-managed pod",

<!-- 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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli


Question: } return nil, fmt.Errorf("multiple volume plugins matched: %s", strings.Join(matchedPluginNames, ",")) } <ins> // Issue warning if the matched provider is deprecated if detail, ok := deprecatedVolumeProviders[matches[0].GetPluginName()]; ok { klog.Warningf("WARNING: %s built-in volume provider is now deprecated. %s", matches[0].GetPluginName(), detail) } </ins> return matches[0], nil }

The plugin and/or the code behind the plugin does not seem to be maintained, is it time to deprecate it?
/sig storage
cc ?
/area code-organization
LGTM


Question: //Test Case 1: Check if anotations are copied properly from deployment to RS t.Run("SetNewReplicaSetAnnotations", func(t *testing.T) { <del> //Try to set the increment revision from 1 through 20 for i := 0; i < 20; i++ { </del> <ins> //Try to set the increment revision from 11 through 20 for i := 10; i < 20; i++ { </ins> nextRevision := fmt.Sprintf("%d", i+1) <del> SetNewReplicaSetAnnotations(&tDeployment, &tRS, nextRevision, true) </del> <ins> SetNewReplicaSetAnnotations(&tDeployment, &tRS, nextRevision, true, 5) </ins> //Now the ReplicaSets Revision Annotation should be i+1 <ins> if i >= 12 { expectedHistoryAnnotation := fmt.Sprintf("%d,%d", i-1, i) if tRS.Annotations[RevisionHistoryAnnotation] != expectedHistoryAnnotation { t.Errorf("Revision History Expected=%s Obtained=%s", expectedHistoryAnnotation, tRS.Annotations[RevisionHistoryAnnotation]) } } </ins> if tRS.Annotations[RevisionAnnotation] != nextRevision { t.Errorf("Revision Expected=%s Obtained=%s", nextRevision, tRS.Annotations[RevisionAnnotation]) }

What happened: We created a Deployment and continuously updated an annotation on it periodically for a week. Eventually, we noticed errors in the controller-manager logs due to the annotation growing too large. Example annotations: controller-manager error: What you expected to happen: that do not change the revision number should not be to the revision history. revision history should be capped at a fixed number of elements, it should not be possible to have unbounded growth for Deployments that are frequently updated. How to reproduce it (as minimally and precisely as possible): a Deployment modify an annotation on it and note that the annotation gets the same number appended every time. Environment: Kubernetes version (use ):
/sig scalability Not 100% sure where this one fits, I couldn't determine which group owns the Deployment/ReplicaSet controllers, but this is a scalability problem
/sig apps
Agree with these, and if the limit is hit, the beginning of the history can be removed.
/assign


Question: func (os *OpenStack) GetDevicePathBySerialID(volumeID string) string { // Build a list of candidate device paths. // Certain Nova drivers will set the disk serial ID, including the Cinder volume id. <ins> // Newer OpenStacks may not truncate the volumeID to 20 chars. </ins> candidateDeviceNodes := []string{ // KVM fmt.Sprintf("virtio-%s", volumeID[:20]), <ins> fmt.Sprintf("virtio-%s", volumeID), </ins> // KVM virtio-scsi fmt.Sprintf("scsi-0QEMU_QEMU_HARDDISK_%s", volumeID[:20]), <ins> fmt.Sprintf("scsi-0QEMU_QEMU_HARDDISK_%s", volumeID), </ins> // ESXi fmt.Sprintf("wwn-0x%s", strings.Replace(volumeID, "-", "", -1)), }

What happened: OpenStack Train with StorageClass the volume attachment succeeds to the node but the kubelet fails to find the attached volume. When a pod attempts to use the volume it becomes stuck in state . Investigation in OpenStack shows the volume is attached to the node. Further, we confirmed the volume is attached to the node, appears as and with a symbolic links as and . Further investigation has determined that the underlying issue is that the volume detection truncates the volume ID at 20 characters while the OpenStack volume ID is 36 characters. Comparing to running on OpenStack 13, we find the symbolic link at is truncated at 20 characters and everything works, but in OpenStack Train this symbolic link is not truncated. We tracked this back through the configuration in : And then used to confirm on OpenStack 13 this value is truncated: But on OpenStack Train it is not:
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 /assign


Question: if err != nil { return err } <ins> if volume.Status == VolumeAvailableStatus { // "available" is fine since that means the volume is detached from instance already. glog.V(2).Infof("volume: %s has been detached from compute: %s ", volume.ID, instanceID) return nil } </ins> if volume.Status != VolumeInUseStatus { errmsg := fmt.Sprintf("can not detach volume %s, its status is %s.", volume.Name, volume.Status) glog.Errorf(errmsg)

When detaching disk, if the volume status is already available, detach should return true instead of error.
/sig openstack
Related to


Question: }, } lockPath14x, lockPath16x := getLockPaths() <ins> // the lockPath14x is a UNIX socket which is cleaned up automatically on close, but the // lockPath16x is a plain file which is not cleaned up. defer os.Remove(lockPath16x) </ins> runner := newInternal(&fexec, ProtocolIPv4, lockPath14x, lockPath16x) err := runner.RestoreAll([]byte{}, NoFlushTables, RestoreCounters)

<!-- 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: files like: are being created, I think from the "unit" tests. What you expected to happen: running tests should not leave files in tree, especially not tracked by git! How to reproduce it (as minimally and precisely as possible): ? I think? Anything else we need to know?: spotted in a PR commit Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig network /assign
I'm also finding an file while working on this locally??? /triage accepted
I suspect , which introduced these lockfile paths and removed deferred removal
is a simple approach to mitigate, but it doesn't solve cluttering the source tree with leaked files. I'm not sure we actually want to take that approach.


Question: // mapper. func (e ShortcutExpander) VersionAndKindForResource(resource string) (defaultVersion, kind string, err error) { resource = expandResourceShortcut(resource) <del> return e.RESTMapper.VersionAndKindForResource(resource) </del> <ins> defaultVersion, kind, err = e.RESTMapper.VersionAndKindForResource(resource) // TODO: remove this once v1beta1 and v1beta2 are deprecated if err == nil && kind == "Minion" { err = fmt.Errorf("Alias minion(s) is deprecated. Use node(s) instead") } return defaultVersion, kind, err </ins> } // expandResourceShortcut will return the expanded version of resource

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: configs[AuthenticatedWindowsNanoServer] = Config{gcAuthenticatedRegistry, "windows-nanoserver", "v1"} configs[APIServer] = Config{promoterE2eRegistry, "sample-apiserver", "1.17.4"} configs[AppArmorLoader] = Config{promoterE2eRegistry, "apparmor-loader", "1.3"} <del> configs[BusyBox] = Config{dockerLibraryRegistry, "busybox", "1.29"} </del> <ins> configs[BusyBox] = Config{promoterE2eRegistry, "busybox", "1.29"} </ins> configs[CheckMetadataConcealment] = Config{promoterE2eRegistry, "metadata-concealment", "1.6"} configs[CudaVectorAdd] = Config{e2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{promoterE2eRegistry, "cuda-vector-add", "2.2"} configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "buster-v1.5.0"} configs[EchoServer] = Config{promoterE2eRegistry, "echoserver", "2.3"} configs[Etcd] = Config{gcEtcdRegistry, "etcd", "3.4.13-0"} <del> configs[GlusterDynamicProvisioner] = Config{dockerGluster, "glusterdynamic-provisioner", "v1.0"} configs[Httpd] = Config{dockerLibraryRegistry, "httpd", "2.4.38-alpine"} configs[HttpdNew] = Config{dockerLibraryRegistry, "httpd", "2.4.39-alpine"} </del> <ins> configs[GlusterDynamicProvisioner] = Config{promoterE2eRegistry, "glusterdynamic-provisioner", "v1.0"} configs[Httpd] = Config{promoterE2eRegistry, "httpd", "2.4.38-alpine"} configs[HttpdNew] = Config{promoterE2eRegistry, "httpd", "2.4.39-alpine"} </ins> configs[InvalidRegistryImage] = Config{invalidRegistry, "alpine", "3.1"} configs[IpcUtils] = Config{promoterE2eRegistry, "ipc-utils", "1.2"} configs[JessieDnsutils] = Config{promoterE2eRegistry, "jessie-dnsutils", "1.4"} configs[Kitten] = Config{promoterE2eRegistry, "kitten", "1.4"} configs[Nautilus] = Config{promoterE2eRegistry, "nautilus", "1.4"} configs[NFSProvisioner] = Config{sigStorageRegistry, "nfs-provisioner", "v2.2.2"} <del> configs[Nginx] = Config{dockerLibraryRegistry, "nginx", "1.14-alpine"} configs[NginxNew] = Config{dockerLibraryRegistry, "nginx", "1.15-alpine"} </del> <ins> configs[Nginx] = Config{promoterE2eRegistry, "nginx", "1.14-alpine"} configs[NginxNew] = Config{promoterE2eRegistry, "nginx", "1.15-alpine"} </ins> configs[NodePerfNpbEp] = Config{promoterE2eRegistry, "node-perf/npb-ep", "1.1"} configs[NodePerfNpbIs] = Config{promoterE2eRegistry, "node-perf/npb-is", "1.1"} configs[NodePerfTfWideDeep] = Config{promoterE2eRegistry, "node-perf/tf-wide-deep", "1.1"}

Part of umbrella to migrate kubernetes e2e test images/registries to community-owned infrastructure: The following images are used by 1.20 e2e tests We should migrate them to community owned infrastructure (ref: for deciding how to implement a mirror registry) We should consider doing this for release branches as well, which may use different images/tags. So these wouldn't necessarily be cherry-picks Two possible approaches: change the registry in source (I would prefer eliminating the extra "docker library" registry, and consolidate to a single e2e test image registry) start running tests with a config that swaps out for some other registry /sig testing /sig release /area release-eng /wg k8s-infra /milestone v1.21
/kind cleanup
/triage accepted /help cc: Give a shout if any of you are interested in working on this!
I'm in! /assign
/remove-help
cc
/cc
I've had 2 PRs opened for this, before it was decited that the test jobs would use the registry mirror configuration. Has there been any consensus on the approach? If so, I can un-abandon these PRs if necessary:
ooh thanks for sharing I don't think there has been any consensus, though I personally think your work on kubernetes/kubernetes is relevant, especially that you've covered everything except gluster and redis.
We already have the redis image here [1], we'll just have to trigger a job for it afterwards. Indeed, I was missing the gluster image, I only considered the image for it.
so I've been thinking about this for a bit and I'm a bit concerned with the visibility of this setup to test authors -- I'm not sure if this is straightforward / intuitive enough for them to follow. alternatively, are there other lighter (in terms of maintenance) solutions that we can pursue?
Hm, what do you mean by the visibility of this setup of test authors? If I'm not mistaken, the current goal is to not rely so heavily on dockerhub for testing anymore. For this purpose we are mirroring these images into our own registries, and then we are going to update to use our own registry instead of the dockerhub one. Test authors shouldn't be impacted by this, IMO. From their point of view, it's the same image, from a different source.

And in terms of maintenance... hm, techically, if someone would want to use an newer image, say , so it would be consistent.
yes, I think we're on the same page on this yeah what I'm wondering is: are there ways we make it even less significant work on the first step of modifying and files? if that step could disappear altogether, especially in scenario of adding new images, that would be great.
I don't really see how. Other images are doing something similar too. For example, the pause image also has its BASEIMAGEs and VERSION in its Makefile. Not all images are built exactly the same, or have the same base image, or are built for the same arch types. Some of them are from scratch, others are from an alpine image, others are from a different alpine image, others are from a debian image... and then we also have windows base images. So, having those BASEIMAGE files addresses this issue. Plus, it also allows us to control what platforms we build for and what we test for. For example, the s390x support wasn't there from the start, it was afterwards. Another example, we want to add the base images at some point. Anyways, modifying the BASEIMAGE files is not very common, but when it is, there's a good reason behind it, so it can't really be optional. Plus, adding / modifying the BASEIMAGE and VERSION files is not significant work. For example, mirroring the 7 images in this PR [1] probably took me ~10 minutes or so. From what I can tell, you want some fast way to just say: "mirror me this image entirely onto our registry". I don't know if we have something like that, and if we do, it'll probably also mirror images with arch types we don't need, and most likely won't have images for platforms we actually need (for example, the ` images on dockerhub does not have any Windows images, but we need them). The test images building process for the test images was not designed for mirroring images, but it can easily do it and we can use it to do so. In addition to that, we can even extend those manifest lists with Windows support [2]. [1] [2]
oh right, apologies for the confusion.

I was referring to having a Dockerfile as a whole, but your explanation is very helpful for me to gain more context about image usage in our infrastructure -- thank you for elaborating I agree the what isn't significant, but the where worries me a bit. I guess in some ways I kind of wish that there is way for this work to simply exist in without touching k/k proper, though now I'm not too sure if that would be overall less complex than this approach. yeah, I was trying to find more solutions towards this direction though I haven't found anything significant which aligns with this topic.
/priority important-soon
In order to complete this, we are going to need these 2 trivial PRs: Retrigger image builder jobs for some images: Small fix for Windows httpd images:
seems like much of the work has been done by Claudiu or I do not have access to finish -- I'll unassign myself to keep this aligned with the state of things /unassign
/assign who has done a lot of the work for this


Question: // TODO (vladimirvivien) would be nice to name socket with a .sock extension // for consistency. csiAddrTemplate = "/var/lib/kubelet/plugins/%v/csi.sock" <del> csiTimeout      = 15 * time.Second </del> <ins> csiTimeout      = 2 * time.Minute </ins> volNameSep      = "^" volDataFileName = "vol_data.json" fsTypeBlockName = "block"

<!-- 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: attach/WaitForAttach timeout value is too small in CSI driver, it's all 15s which is really too small: Compared to built-in driver timeout, it's really too small: is , total is What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.13 - 1.15 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 storage /assign


Question: for _, extIP := range svcInfo.ExternalIPStrings() { conntrackCleanupServiceIPs.Insert(extIP) } <ins> for _, lbIP := range svcInfo.LoadBalancerIPStrings() { conntrackCleanupServiceIPs.Insert(lbIP) } </ins> nodePort := svcInfo.NodePort() if svcInfo.Protocol() == v1.ProtocolUDP && nodePort != 0 { klog.V(2).Infof("Stale %s service NodePort %v -> %d", strings.ToLower(string(svcInfo.Protocol())), svcPortName, nodePort)

<!-- 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 --UDP traffic to a Pod behind a LoadBalancer Service exposing a UDP listener service is blackholed when the replacement Pod is scheduled on the same node as the "old" Pod. A new Pod that gets provisioned (replacing the previous one) will receive traffic once it's ready. a UDP Listener Pod (single pod) and using nodeSelector ensure it runs on a specific node the Pod behind a LoadBalancer Service continuous stream of UDP packets from outside the cluster to the External IP of the Service that traffic is correctly received the Pod and observe as a new one is created, traffic should now be blackholed and not reaching the "new" Pod After the new Pod is recreated, we noticed the following entries on the node: notice that the <SVC EXT IPappears here both in the original and the NATed , this is wrong and I suspect happens because the conntrack for the old Pod were flushed before the iptables rules for the new Pod were created (?) and in the interim new packets have reached the node and resulted in these incorrect conntrack entries. To "fix" this, we manually deleted the above conntrack entries, and this allowed new correct one to be established based on the now existing iptables nat rule: with this new conntrack entries, the traffic started flowing as expected to the new Pod and notice that the NATed now correctly shows the Pod IP (172.30.3.219) instead of the Service External IP. While spelunking through the GitHub issues and PRs, I found this issue which was addressed in , it does mention that: the service has endpoints available. Since the fix in this PR refers to NodePort, perhaps the same also applies to External IP (i.e. LoadBalancer Service?) or there's something else at play here? AFAICT, this fix is included in v1.20.7 that we are running. Kubernetes version (use ):Cloud provider or hardware configuration: GCP/GKE OS (e.g: ):Kernel (e.g.

): Install tools: Terraform (with google provider) Network plugin and version (if this is a network-related bug): Others:
/sig network
According to GCP support (since we hit this on a GKE cluster) there's already a fix for this bug and it in v1.21, however I'm unable to find to link it here (hope they can provide the link shortly).
GCP support referenced as the fix for this issue, however this was already merged and released in v1.20.4 but we are running v1.20.7, so should have the fix already, so the status is unclear at this point.
thanks for the detailed report, at first sight we do clean the external ips is it possible to set kube-proxy in a log level of 2 and capture the logs from the node to correlate with the time it happends, and understand why those entries are not being deleted?
Hey we can try that, however since this is a GKE environment I'd have to check how/if we can change kube-proxy log level. My understanding of the issue is that it's not that the conntrack entries are flushed, is that they are flushed before the nat iptables rules are created, causing faulty conntrack entries to be created in the interim (since the udp packets are incoming all the time).
I'm having some miscommunication about the availability of fix in with GCP/GKE support and was hoping you could confirm that is included in v1.20.5 (as per the release notes there? ) and per the cherry-pick PR GCP Support claim that this change is incorporated in v1.21 and we should wait for v1.21 to be available in GKE.
I see the commit in 1.20.5 , this is the cherry-pick The conntrack entries are always deleted after the conntrack entries are created, there is some code that detects that a service goes stale and based on that it deletes the entries.

I think that current code detects this case, at least I know it works when the service goes from 0 to 1 endpoint, that is why the logs will be useful, we can see exactly what happens ...
Thanks for confirming I just checked and seem to be already running in log level 2: I looked back at the logs when this issue was identified and I see the following entries: This two messages and only these two repeat every time we tried to rollout the deployment. is indeed the and is the ClusterIP of the service: but every time we tried, we ended up with these stale conntrack entries I mentioned in the OP and only after deleting them would the udp packet start flowing into the "new" pod.
oh wait, by external IP you mean ?
/triage accepted /assign
here you go, having good reports on bugs make them easy to spot ;)
indeed! I apologize if I wasn't clear indeed I was referring to the LoadBalancer Service External IP. Thanks for fix!!! But now I'm a bit confused, since I understood that LoadBalancer Service External IP == LoadBalancer Ingress IP, but I see these are two separate attributes? so for example: These are the same IP, but internally they are separate attributes?
hmm I don't know how kubectl prints the information, but you can check the fields with and you could see that ExternalIPs and LoadBalancer.IngressIP are different fields, actually one is in the Status and other in the Spec
interesting, so in the output, I can only see the , there's actually no mention of here: That's why I always assumed that this is referring to the same thing/attribute/field.


Question: } // NewNetLinkHandle will create an EmptyHandle <del> func NewNetLinkHandle() NetLinkHandle { </del> <ins> func NewNetLinkHandle(ipv6 bool) NetLinkHandle { </ins> return &emptyHandle{} }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster with proxy-mode=ipvs the entries for NodePort in ipvs are created for ipv4 addresses. The target's (if there are any) consists of ipv6 addresses (wrongly) interpreted as ipv4; Attempts to use the NodePort with ipv6 addresses are black-holed. What you expected to happen: Ipv6 addresses to the nodes should be used for NotePort and the LB-targets shall be the ipv6 address of the pods. Traffic to NodePorts shall be distributed among the (ipv6) endpoints. How to reproduce it (as minimally and precisely as possible): Setup an ipv6-only cluster Create a service with type with endpoints Try to connect to the NodePort Do Anything else we need to know?: The nodes have both ipv4 and ipv6 addresses and it is possible that if the nodes only had ipv6 addresses it would work (I havn't tested). But even in an ipv6-only k8s cluster the nodes almost always need ipv4 addresses for other purposes. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm VMs on Ubuntu 18.04.01 LTS OS (e.g. from /etc/os-release): Own BusyBox based system Kernel (e.g. ):Install tools: None Others:
The NodeIPs() function seem to return only ipv4 addresses.
I can't see why (yet) since is used in the GetLocalAddresses function
/cc Please give a hint before I dive into the netlink code.
This issue is used as an example here;
The functions filters on Src != nil . But ipv6 addresses seems to have Src == nil always. As it is this function will never return any ipv6 addresses.


Question: } }, }, <ins> { name: "caKeyPresent-false for v1.11.3", cfg: &kubeadmapi.InitConfiguration{ APIEndpoint: kubeadmapi.APIEndpoint{AdvertiseAddress: "1.2.3.4"}, ClusterConfiguration: kubeadmapi.ClusterConfiguration{ KubernetesVersion: "v1.11.3", Networking:        kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, }, }, caKeyPresent: false, expectedArgFunc: func(tmpdir string) []string { return []string{ "kube-controller-manager", "--address=127.0.0.1", "--leader-elect=true", "--kubeconfig=" + kubeadmconstants.KubernetesDir + "/controller-manager.conf", "--root-ca-file=" + tmpdir + "/ca.crt", "--service-account-private-key-file=" + tmpdir + "/sa.key", "--cluster-signing-cert-file=", "--cluster-signing-key-file=", "--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", } }, }, { name: "caKeyPresent true for v1.11.3", cfg: &kubeadmapi.InitConfiguration{ APIEndpoint: kubeadmapi.APIEndpoint{AdvertiseAddress: "1.2.3.4"}, ClusterConfiguration: kubeadmapi.ClusterConfiguration{ KubernetesVersion: "v1.11.3", Networking:        kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, }, }, caKeyPresent: true, expectedArgFunc: func(tmpdir string) []string { return []string{ "kube-controller-manager", "--address=127.0.0.1", "--leader-elect=true", "--kubeconfig=" + kubeadmconstants.KubernetesDir + "/controller-manager.conf", "--root-ca-file=" + tmpdir + "/ca.crt", "--service-account-private-key-file=" + tmpdir + "/sa.key", "--cluster-signing-cert-file=" + tmpdir + "/ca.crt", "--cluster-signing-key-file=" + tmpdir + "/ca.key", "--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", } }, }, </ins> } for _, test := range tests {

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create an old version k8s cluster, the controller manager pod can not work well. The command like this : "kubeadm init --kubernetes-version=v1.11.2" The error of kube controller manager pod like this : What you expected to happen: The controller manager pod can work well. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): Install tools: kubeadm Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-sig contributor-experience /area kubeadm
Please, use when filing kubeadm issues. /sig cluster-lifecycle
OK, thank you for reminding me.


Question: fakeClient := fake.NewSimpleClientset(objs...) informerFactory := informers.NewSharedInformerFactory(fakeClient, 0) eventBroadcaster := events.NewBroadcaster(&events.EventSinkImpl{Interface: fakeClient.EventsV1()}) <ins> defer eventBroadcaster.Shutdown() </ins> eventRecorder := eventBroadcaster.NewRecorder(scheme.Scheme, fakePermit) outOfTreeRegistry := frameworkruntime.Registry{ fakePermit: newFakePermitPlugin(eventRecorder), } <del> _, ctx := ktesting.NewTestContext(t) ctx, cancel := context.WithCancel(ctx) defer cancel() </del> <ins> tCtx := utiltesting.Init(t) </ins> scheduler, err := New( <del> ctx, </del> <ins> tCtx, </ins> fakeClient, informerFactory, nil,

/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /sig scheduling
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
/assign This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.


Question: "k8s.io/kubernetes/pkg/api/unversioned" client "k8s.io/kubernetes/pkg/client/unversioned" "k8s.io/kubernetes/pkg/util/sets" <del> "k8s.io/kubernetes/pkg/util/system" </del> "k8s.io/kubernetes/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

<!-- 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 --Create a pod: the pod is always , and describes as: kubelet log: Deny the pod orchestration with duplicate volumes, OR the pod can be running successfully. Create a pod with the duplicate pvc as above. Root cause The key of persistent volume info in DSW is named after, and the is a : When getting the unmounted volumes, it uses : In our case, volume will corve the volume in DSW, and the volume info is lost in ASW. Solution: 2 choices: Consider it as an invalid request, and deny creating it. Construct uniqueVolumeName with when the volume is a persistent volume.Kubernetes version (use ): v1.20.4 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 apps /sig node /sig storage
I don't think it's common sense to write duplicate volumes, and people don't use them that way, but if you want to achieve the above YAML intent, you can do it this way so I think it might be better this way if write duplicate volumes
/assign
I recognize your point, but I think kubernetes should validate that.
Yes, I think verification should be as well I'll try to do that
Then I thought about it again, and I think this YAML might sometimes be used this way So it may not be a good idea to say no outright Can you give me some advice ?
, I think that it is possible in some situations that a pod is running with duplicate persistent volume. For example, a container running web application reads application data from a persistent volume and saves logs to another PV.
This seems possible and Thank you for your description of the situation.
Does this address your use case?

I've tried it and it works But does this duplicate PV need to take certain measures, verification failed or can be successful or other pod Always in the phase
/unassign
This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /remove-kind bug /kind support /triage accepted /priority backlog /area documentation /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /kind support /triage accepted /priority backlog /area documentation /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /kind support /triage accepted /priority backlog /area documentation /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hey I am new to open source and will like to contribute to this project can you guide me on what needs to done.
Welcome ! Sure, so the goal is to document that example of a double mount of the same pv. I would put it somewhere here: Which corresponds to this repo:
If you have another idea about the best page to document it, please make it as you think.
are you taking this up , or should i take?
yes, I am taking this up.
/remove-kind support /kind documentation
Ah documentation is a kind... Makes sense. Thx Elana!
Hii after reading docs . I think the example of " double mount of the same PV " needs to be either before or at the end of the page. what did you say? And it may look something like this.

Running pods with the duplicate persistent volume, Example: A container running a web application reads application data from a persistent volume and saves logs to another PV. as the example was mentioned by
Thanks for looking at it. I wonder if that example would nicely add to as it's more hands on than the other page. What do you think?
yeah, docs seems the right place to add the " double mount of the same PV" example. and I think It should be after the . What do you think?
Yes, so now sign the CLA, open a PR and link this issue. We'll see what they say during the review...
I open a PR but still it is not reviewed. Do I need to assign it to someone?
I see your PR and prow has requested review from 2 reviewers... Let's give them one or two days and then we can poke them again
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
cc
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:


Question: "k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/kubectl" <ins> "k8s.io/kubernetes/pkg/kubectl/resource" </ins> "k8s.io/kubernetes/pkg/runtime/schema" "github.com/spf13/cobra"

What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR


Question: tcpCloseWaitTimeout: 10s tcpEstablishedTimeout: 20s featureGates: "all" <del> healthzBindAddress: 1.2.3.4:12345 </del> <ins> healthzBindAddress: "%s" </ins> hostnameOverride: "foo" iptables: masqueradeAll: true

Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? is:issue is:open ipv6 Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): N/A, these are unit test changes in latest master Environment: Cloud provider or hardware configuration: Kubernetes container dev env on Ubuntu 16.04.1 OS (e.g. from /etc/os-release): Ubuntu 16.04.1 Kernel (e.g. ): 4.4.0-78-generic -Ubuntu x8664 GNU/Linux Install tools: Others: What happened: Upon inspection, no IPv6 test cases found in kubernetes/cmd/kube- What you expected to happen: Expect to see some IPv6 test cases exercised for kube-proxy server code (kubernetes/cmd/kube-). Also need some code coverage for negative conditions in How to reproduce it (as minimally and precisely as possible): Run unit tests in kubernetes/cmd/kube- Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig networking
/area ipv6
/sig network


Question: <ins> #!/bin/bash # Copyright 2014 The Kubernetes Authors All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Cleans up resources from the example, assumed to be run from Kubernetes repo root export OPENSHIFT_EXAMPLE=$(pwd)/examples/openshift-origin export OPENSHIFT_CONFIG=${OPENSHIFT_EXAMPLE}/config rm -fr ${OPENSHIFT_CONFIG} cluster/kubectl.sh delete secrets openshift-config cluster/kubectl.sh stop rc openshift cluster/kubectl.sh delete rc openshift cluster/kubectl.sh delete services openshift </ins>

This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.


Question: # See the License for the specific language governing permissions and # limitations under the License. <ins> # This script generates all go files from the corresponding protobuf files. # Usage: `hack/update-generated-protobuf.sh`. </ins> set -o errexit set -o nounset set -o pipefail

What would you like to be : There are many useful scripts in "". For example, I often use and for creating simple k8s cluster quickly. However, there are only few explanation or nothing how to use it. I think it becomes more useful and helpful if some instruction or guidance is explained in each script. Why is this needed: It aims and expects to increase new k8s developers by describing how to use each script. My proposal Add the following description under the copyright for each script file. Overview of the script Simple usage Supplementary explanation(This is option) Other concern I would like to know the purpose of use about hack directory. (e.g. Where to put tools for developers(therefore there is no guidance?).)
I don't know who is in charge of each scripts of hack, but if he agrees the idea of this feature request , I am going to do this task myself!!
/sig testing
I believe there is a script generating swagger/openapi specfilters under hack, but I am still struggling with it. It could be of great help if there is some how-to doc for each scripts.
this basis, why not create a file under the hack folder, because a lot of kk CIs are derived from multiple script commands under the hack. There are already 268+ files under the hack file. For contributors unfamiliar with these, these comments and instructions are helpful to them, and it is also helpful for new contributors to handle pr ci error reports.
/cc What do you think
I think it's good idea to create (It may be easy to understand if the script's explanation is described by category or use in ) Apart from that, it is helpful that the script file itself has a brief description.
When we create , it may tough work if creating it including all scripts explanation at one time. (There are many scripts and I understand only some scripts now.) Regarding , current my idea is to add a description to each script little by little and update the at the same time. This means that will be completed little by little in conjunction with adding the description of each script. In the future, if someone create new script in hack, he also may have to add description of his script into
Self-documenting commands sound useful. A high level overview also sounds useful.

/cc /cc Regarding adding help information, I suggest that we can submit pr in one or several files as a unit, so that we can track and statistics. For the documentation, I think it should be concise and not too long. How about this advice? We can claim tasks through , the pr title yes , i agree with you. [x] kubernetes/hack/benchmark- [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] kubernetes/hack/boilerplate/BUILD [ ] kubernetes/hack/boilerplate/test/BUILD [ ] [ ] [ ] [ ] [ ] kubernetes/hack/BUILD [x] kubernetes/hack/build- [x] kubernetes/hack/build- [x] [ ] kubernetes/hack/conformance/BUILD [ ] [x] kubernetes/hack/dev-build-and- [x] kubernetes/hack/dev-build-and- [x] kubernetes/hack/dev-push- [ ] kubernetes/hack/e2e-internal/BUILD [ ] kubernetes/hack/e2e-internal/e2e-cluster- [ ] kubernetes/hack/e2e-internal/e2e- [ ] kubernetes/hack/e2e-internal/e2e-grow- [ ] kubernetes/hack/e2e-internal/e2e-shrink- [ ] kubernetes/hack/e2e-internal/e2e- [ ] kubernetes/hack/e2e-internal/e2e- [x] kubernetes/hack/e2e-node- [ ] kubernetes/hack/generate- [x] kubernetes/hack/generate- [ ] kubernetes/hack/gen-swagger-doc/gen-swagger- [x] kubernetes/hack/get- [x] kubernetes/hack/ginkgo- [x] kubernetes/hack/grab- [x] kubernetes/hack/install- [ ] kubernetes/hack/jenkins/benchmark- [ ] kubernetes/hack/jenkins/OWNERS [ ] [ ] kubernetes/hack/jenkins/test- [ ] kubernetes/hack/jenkins/verify- [ ] kubernetes/hack/lib/BUILD [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [x] kubernetes/hack/lint- [x] kubernetes/hack/list-feature- [x] kubernetes/hack/local-up- [ ]

kubernetes/hack/make-rules/BUILD [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make-rules/helpers/go2make/BUILD [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/subdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/README [ ]

kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-without-gofiles/README [ ] kubernetes/hack/make-rules/Makefile.manifest [ ] kubernetes/hack/make-rules/make- [ ] kubernetes/hack/make-rules/test- [ ] kubernetes/hack/make-rules/test-e2e- [ ] kubernetes/hack/make-rules/test-e2e- [x] kubernetes/hack/make-rules/test- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/OWNERS [x] kubernetes/hack/pin- [x] kubernetes/hack/print-workspace- [x] kubernetes/hack/run-in- [ ] kubernetes/hack/testdata/auth- [x] [x] [x] kubernetes/hack/testdata/CRD/foo-- [x] kubernetes/hack/testdata/CRD/foo-deleted- [x] kubernetes/hack/testdata/CRD/foo-updated- [x] [x] kubernetes/hack/testdata/CRD/multi-crd-list-- [x] kubernetes/hack/testdata/CRD/multi-crd-list-deleted- [x] kubernetes/hack/testdata/CRD/multi-crd-list-updated- [x] kubernetes/hack/testdata/CRD/multi-crd- [x] [x] [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-multicontainer- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment-with- [x] [x] [x] [x] [x] [x] kubernetes/hack/testdata/filter/pod-apply- [x] kubernetes/hack/testdata/filter/pod-dont- [x]

kubernetes/hack/testdata/frontend- [x] kubernetes/hack/testdata/frontend- [x] kubernetes/hack/testdata/invalid-rc-with-empty- [x] kubernetes/hack/testdata/kubernetes- [x] [x] [x] [x] [x] [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-json- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-list- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-rclist- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-svclist- [x] kubernetes/hack/testdata/multi-resource-yaml- [x] kubernetes/hack/testdata/multi-resource- [x] kubernetes/hack/testdata/null-propagation/deployment- [x] kubernetes/hack/testdata/null-propagation/deployment- [x] kubernetes/hack/testdata/OWNERS [x] kubernetes/hack/testdata/pod- [x] kubernetes/hack/testdata/pod- [x] kubernetes/hack/testdata/pod-with-api- [x] kubernetes/hack/testdata/pod-with-large- [x] kubernetes/hack/testdata/pod-with- [x] [x] [x] [x] [x] kubernetes/hack/testdata/prune- [x] kubernetes/hack/testdata/prune- [x] kubernetes/hack/testdata/recursive/deployment/deployment/nginx- [x] [x] [x] [x] [x] kubernetes/hack/testdata/recursive/pod/pod/busybox- [x] [x] [x] kubernetes/hack/testdata/recursive/pod- [x] kubernetes/hack/testdata/recursive/pod-modify/pod/busybox- [x] kubernetes/hack/testdata/recursive/pod- [x] kubernetes/hack/testdata/recursive/pod- [x] [x] kubernetes/hack/testdata/recursive/rc/rc/busybox- [x] [x] [x] kubernetes/hack/testdata/redis-slave- [x]

kubernetes/hack/testdata/retainKeys/deployment/deployment- [x] kubernetes/hack/testdata/retainKeys/deployment/deployment- [x] kubernetes/hack/testdata/rollingupdate-daemonset- [x] kubernetes/hack/testdata/rollingupdate- [x] kubernetes/hack/testdata/rollingupdate-statefulset- [x] kubernetes/hack/testdata/rollingupdate- [x] kubernetes/hack/testdata/scale-deploy-1.yaml [x] kubernetes/hack/testdata/scale-deploy-2.yaml [x] kubernetes/hack/testdata/scale-deploy-3.yaml [x] [x] kubernetes/hack/testdata/service- [x] kubernetes/hack/testdata/service- [x] kubernetes/hack/testdata/sorted-pods/sorted- [x] kubernetes/hack/testdata/sorted-pods/sorted- [x] kubernetes/hack/testdata/sorted-pods/sorted- [ ] [ ] [x] kubernetes/hack/test- [ ] kubernetes/hack/test- [x] kubernetes/hack/update- [ ] kubernetes/hack/update- [x] kubernetes/hack/update- [ ] kubernetes/hack/update-generated-api-compatibility- [x] kubernetes/hack/update-generated-device-plugin- [ ] kubernetes/hack/update-generated-device- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-kms- [ ] kubernetes/hack/update-generated- [x] kubernetes/hack/update-generated-kubelet-plugin-registration- [ ] kubernetes/hack/update-generated-kubelet-plugin- [x] kubernetes/hack/update-generated-pod-resources- [ ] kubernetes/hack/update-generated-pod- [ ] kubernetes/hack/update-generated-protobuf- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-runtime- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-swagger- [x] kubernetes/hack/update- [x] kubernetes/hack/update-import- [ ] kubernetes/hack/update-openapi- [x] kubernetes/hack/update- [ ] kubernetes/hack/update-vendor- [ ] kubernetes/hack/update- [ ] kubernetes/hack/update-workspace- [x] kubernetes/hack/verify-

[x] kubernetes/hack/verify-api- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-cli- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-conformance- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-external-dependencies- [ ] kubernetes/hack/verify-flags/excluded- [x] kubernetes/hack/verify-flags/OWNERS [x] kubernetes/hack/OWNERS [ ] kubernetes/hack/verify-flags- [x] kubernetes/hack/verify-generated-device- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-files- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-kubelet-plugin- [x] kubernetes/hack/verify-generated-pod- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-swagger- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-import- [x] kubernetes/hack/verify-import- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-no-vendor- [x] kubernetes/hack/verify-openapi- [x] kubernetes/hack/verify-pkg- [x] kubernetes/hack/verify-publishing- [x] kubernetes/hack/verify-readonly- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-staging-meta- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-typecheck- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-vendor- [x]

kubernetes/hack/verify- [x]
i will pick up , i will do it step by step.
I agree with your idea, and thanks the checkbox to check progress. there are many scripts, so let's work together!
/assign /assign
I will pick up hack/verify-
I will pick up hack/verify-
I will pick up hack/verify- (all of verify scripts). But there are large number of scripts(over 40), I want to split it into two or three PRs.
I will pick up hack/update-
I will pick up these scripts. kubernetes/hack/benchmark- kubernetes/hack/build- kubernetes/hack/build- kubernetes/hack/dev-build-and- kubernetes/hack/dev-build-and- kubernetes/hack/dev-push- kubernetes/hack/e2e-node- kubernetes/hack/generate-
I will pick up these scripts get- ginkgo- grab- install- lint- list-feature- local-up- pin- print-workspace- run-in- test- test-
How about this now? /help Marking this tag so that others can easily access it.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : How about this now? /help Marking this tag so that others can easily access it. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I think we've finished adding simple explanations to the almost scripts. It seems that several scripts of update- does not complete yet. I think we may able to close after that work.
I will pick up these scripts:
/assign


Question: t.Errorf("%v: Unexpected error: %v", name, err) return } <ins> if item.reqHost != "" { req.Host = item.reqHost } </ins> resp, err := item.transport.RoundTrip(req) if err != nil { t.Errorf("%v: Unexpected error: %v", name, err)

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. 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


Question: // TestBootstrapTokenAuth tests the bootstrap token auth provider func TestBootstrapTokenAuth(t *testing.T) { <del> tokenID, err := bootstraputil.GenerateTokenID() if err != nil { t.Fatalf("unexpected error: %v", err) } secret, err := bootstraputil.GenerateTokenSecret() if err != nil { t.Fatalf("unexpected error: %v", err) } </del> <ins> validTokenID := "token1" validSecret := "validtokensecret" </ins> var bootstrapSecretValid = &corev1.Secret{ ObjectMeta: metav1.ObjectMeta{ Namespace: metav1.NamespaceSystem,

Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.


Question: t.Fatalf(`expected error "%s"`, expectedError) } <ins> func TestDontAllowForceApplyWithServerSide(t *testing.T) { expectedError := "error: --force cannot be used with --server-side" cmdutil.BehaviorOnFatal(func(str string, code int) { panic(str) }) defer func() { actualError := recover() if expectedError != actualError { t.Fatalf(`expected error "%s", but got "%s"`, expectedError, actualError) } }() tf := cmdtesting.NewTestFactory().WithNamespace("test") defer tf.Cleanup() tf.ClientConfigVal = cmdtesting.DefaultClientConfig() ioStreams, _, _, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdApply("kubectl", tf, ioStreams) cmd.Flags().Set("filename", filenameRC) cmd.Flags().Set("server-side", "true") cmd.Flags().Set("force", "true") cmd.Run(cmd, []string{}) t.Fatalf(`expected error "%s"`, expectedError) } </ins> func TestDontAllowApplyWithPodGeneratedName(t *testing.T) { expectedError := "error: from testing-: cannot use generate name with apply" cmdutil.BehaviorOnFatal(func(str string, code int) {

What happened: A resource is not replaced (deleted and recreated) when passing the flag to and the change cannot be applied. What you expected to happen: I expected the service to be replaced. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ):
/sig api-machinery /wg api-expression
/sig cli
/cc
Good to know, that's certainly worthy of a fix.
/cc
This is slightly related: If we want to support we could try and make the behavior clearer.
Can you weigh in on how important this is? We feel that is super, super dangerous in general. It's also very easy to confuse it with for server side apply, so it's extra dangerous. Do we need to implement this field for this command? Can we give an error, like "use one of: --force-conflicts or --delete-then-create"? Can SIG CLI do something about this flag in general?
/cc
Noted, I'll make sure this is in the agenda for the next sig-cli meeting.
I don't think the two are related. is now error-ing when used with , but it'll still fail with server-side apply.
You're right... my recall was bad. I deleted my comment where I thought was this, but it is not. Sorry about that
Looks like in the SIG-CLI meeting it was decided to not enable the user to use the and flag together. kubectl should fail immediately with a warning that should not be used with server side apply. Do you mind if I start working on this issue? I will reach out to you and other members of the SIG to get more details needed. I am a new contributor to k8s and would like to work on this issue.
Thanks for summarizing the discussion! I'd love to see you submit a PR for that, that's awesome!
/assign /lifecycle-active


Question: // Testing a 1.17 version of the sample-apiserver TestSampleAPIServer(f, aggrclient, imageutils.GetE2EImage(imageutils.APIServer)) }) }) func cleanTest(client clientset.Interface, aggrclient *aggregatorclient.Clientset, namespace string) {

[x] test pr : kuberenetes/kubernetes# [x] two weeks soak start date : testgrid-link [x] two weeks soak end date : [x] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. With this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Addressing the following endpoints in this document; Using the current e2e test as a template, create an APIService for Using the REST client, read the APIService status (readApiregistrationV1APIServiceStatus) and confirm the value of . Using the REST client, patch the APIService (patchApiregistrationV1APIService) before confirming that it has been updated. Using the REST client, list all APIServices in the cluster (listApiregistrationV1APIService) before confirming that can be found. Clean up APIService resources used by the test. 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. This query shows the endpoints hit within a short period of running the e2e test example endpoint | useragent ---------------------------------------|
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator2 readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator2 (6 rows) Based on the initial APIsnoop query and the results listed above there are three new endpoints hit.

If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted


Question: <del> 2.49 </del> <ins> 2.50 </ins>

How to repro: an agnhost pod listening on sctp into the pod and use the connect command to probe against the same pod The stack trace that points to and this is from the vendored library , /kind bug /sig network /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Run an agnhost pod listening on sctpExec into the pod and use the connect command to probe against the same pod The stack trace that points to /sig network /help </details
/assign
/triage accepted
here we are immediately closing the connection after successful connect leading to EOF at server end (it is expecting data) causing the failure. We can tweak this to connect send some data just like UDP and then exit? Works locally writing "hostname" to the connection. [EDIT] For me it sometimes failed with EOF, sometime with nil pointer exception at . This reads sock opts via syscall and we immediately close the connection .. kind of a race between the client closing connection and server reading fds?
the panic seems a bug in that project, no? Also SCTP, has a establishment handshake, so the data should not be relevant in this case
returns fd and socket address, for is used to implement (always read from struct field). The SCTP implementation discards the returned socket address by call. , and is always a new syscall (). In our case the client immediately closes the connection, there can be chances where SCTPGETPEERADDRS will fail and will return nil in these cases. I think this is reasonable for their project. We call and panic is raised by calling on nil object. We can easily avoid this by not null check.

Also, I strongly believe that the client handling should be done in a separate go-routine instead of the main loop to avoid errors like this crashing the pod. [EDIT] The client in our case needs to send some data after connection, or else the server will throw EOF and we currently have assertions that use for errors.
panicing does not seem very reasonable It looks to me that the problem is that the SCTPConn struct needs to check if the connection is still valid before trying to access the file descriptor , see the std library implementation and then, all methods implement this check to me it is a bug on the implementation
The implementation is not causing any panic, it simply returns nil. Panic is caused when we try to call on nil object.
oh, sorry, my bad I should read your comment with more detail, is well explained there I recognize I have zero idea of how sctp works internally, maybe we can just be more resilient on our tests and code and detect if is nil and avoid getting into the complexity of this protocol ... sending some random data also sounds good, we do this for udp IIRC
are you able to send a PR to add those improvements to the test image?


Question: as.Equal(len(runContainerOpts.Devices), len(expectedResp.Devices)) as.Equal(len(runContainerOpts.Mounts), len(expectedResp.Mounts)) as.Equal(len(runContainerOpts.Envs), len(expectedResp.Envs)) <ins> pod2 := makePod(v1.ResourceList{ v1.ResourceName(res1.resourceName): *resource.NewQuantity(int64(0), resource.DecimalSI)}) activePods = append(activePods, pod2) podsStub.updateActivePods(activePods) err = testManager.Allocate(pod2, &pod2.Spec.Containers[0]) as.Nil(err) _, err = testManager.GetDeviceRunContainerOptions(pod2, &pod2.Spec.Containers[0]) as.Nil(err) select { case <-time.After(time.Millisecond): t.Log("When pod resourceQuantity is 0,  PreStartContainer RPC stub will be skipped") case <-ch: break } </ins> } func TestResetExtendedResource(t *testing.T) {

<!-- 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 I register a device plugin and set the option in true, then when I create a pod and specify this resource as 0 in yaml, an error will be reported. Examples are as follows. The request to register the device pluginA pod yaml with the resource 0kubelet return error What you expected to happen: I think when the kubelet calls , the resource value should be checked. If it is 0, the step should be skipped to avoid errors. How to reproduce it (as minimally and precisely as possible): Register a device plugin which set option is true Create a pod with the above resource 0 Anything else we need to know?: In fact, when the amount of requested resources is 0, devicemanager will get the number of allocated devices as nil, resulting in the internal cache not storing the application resource information corresponding to the container. But if is set to true at the same time, then devicemanager will check podDevices cache. The two processing steps contradict each other so it will return an error.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node