jiebi/CodeConvo huggingface dataset:
Change:
"//vendor:k8s.io/apiserver/pkg/authentication/request/union", "//vendor:k8s.io/apiserver/pkg/authentication/request/x509", "//vendor:k8s.io/apiserver/pkg/authentication/token/tokenfile", <del> "//vendor:k8s.io/apiserver/pkg/authentication/user", </del> "//vendor:k8s.io/apiserver/plugin/pkg/authenticator/password/keystone", "//vendor:k8s.io/apiserver/plugin/pkg/authenticator/password/passwordfile", "//vendor:k8s.io/apiserver/plugin/pkg/authenticator/request/basicauth",

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
if framework.NodeOSDistroIs("windows") { privileged = false } <del> injectorPod, err := runVolumeTesterPod(f.ClientSet, config, "injector", privileged, fsGroup, tests) </del> <ins> injectorPod, err := runVolumeTesterPod(f.ClientSet, config, "injector", privileged, fsGroup, tests, false /*slow*/) </ins> if err != nil { framework.Failf("Failed to create injector pod: %v", err) return

Discussion:
Which jobs are flaking: gce-cos-master-alpha-features Which test(s) are flaking: [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] provisioning should provision storage with snapshot data source [Feature:VolumeSnapshotDataSource] Testgrid link: Reason for failure: It takes 6 minutes to start a pod with PVC that has been restored from a snapshot, while the test waits only 5 minutes: csi-attacher sidecar says: Perhaps the provisioner should wait until the volume is ready to be used? That may not help with this test timeout, as PVC is provisioned after the Pod is scheduled and the total time could be the same. All this is caused by my PR to test block snapshots, It reworked the tests from using . If snapshots are slow, should all persistent storage tests use / ?
/sig storage
Generally, cutting a snapshot is quick, but uploading can take longer. Does provisioner wait until the snapshot is "ready" before returning success?
cc
(But yes, we should increase the timeout because overall time will still be longer no matter which order we take)
The provisioner does not wait. If snapshot is not readyToUse, creating a volume from it will fail. I'll have to check to see if there's logic to wait in the e2e test. Regarding GCE PD, at restore time, do we need to download the snapshot from object store? If that's the case, it could take a while to download as well.
volume controller should keep trying until snapshot is ready. Looks like attacher tried to attach while disk is not ready. It is strange because I think attach only happen after volume is successfully provisioned.
AFAIK, most cloud providers' snapshot ATM will be uploaded to some remote when taking, and will be downloaded when restoring. GCE PD is one of them.
It's not taking snapshots what slows the test, it's restoring it - returns quickly, but the returned volume is not really usable and attach fails for ~4 minutes until the snapshot is fully restored somewhere in GCE. Now that I am thinking about it, maybe it's better if the driver returns the volume early, so it does not end up orphaned when user deletes corresponding PVC and the provisioner is restarted at the same time.

Anyway, I'll extend the timeout in volume checks. /assign
Which brings me to idea: what about other storage backends? Some of them may take even longer that 10 minutes to restore a snapshot. Or more than 5 minutes to provision an empty volume and run a pod. There should be some configuration of timeouts (timeout multiplier?) for
I opened to investigate from GCE side if this behavior is expected.
Change:
"k8s.io/kubernetes/pkg/scheduler/framework/plugins/nodepreferavoidpods" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/noderesources" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/nodevolumelimits" <ins> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/podtopologyspread" </ins> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/tainttoleration" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/volumebinding" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/volumerestrictions"

Discussion:
What would you like to be : Add a filter plugin that calls into EvenPodsSpread predicate, example Why is this needed: Part of /sig scheduling /help /priority important-soon
/assign
/remove-help
/retitle: [migration phase 1] EvenPodsSpread as filter plugin
/retitle [migration phase 1] EvenPodsSpread as filter plugin
/assign /unassign
May I take over this?
is going to take this over after the offline discussion, and he is familiar with EvenPodsSpread
IC, thanks a lot.
Change:
framework.ExpectNoError(err, "Timeout while waiting to confirm PV %q deletion", retrievedPV.Name) }) <del> ginkgo.It("should apply changes to a pv/pvc status", func(ctx context.Context) { </del> <ins> /* Release: v1.29 Testname: PersistentVolumes(Claims), apply changes to a pv/pvc status Description: Creating PV and PVC MUST succeed. Listing PVs with a labelSelector MUST succeed. Listing PVCs in a namespace MUST succeed. Reading PVC status MUST succeed with a valid phase found. Reading PV status MUST succeed with a valid phase found. Patching the PVC status MUST succeed with its new condition found. Patching the PV status MUST succeed with the new reason/message found. Updating the PVC status MUST succeed with its new condition found. Updating the PV status MUST succeed with the new reason/message found. */ framework.ConformanceIt("should apply changes to a pv/pvc status", func(ctx context.Context) { </ins> pvClient := c.CoreV1().PersistentVolumes() pvcClient := c.CoreV1().PersistentVolumeClaims(ns)

Discussion:
[x] test approval issue : [x] test pr : [x] Flake [x] two weeks soak end date : 31 Oct 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 6 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 6 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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
Change:
"github.com/spf13/cobra" <ins> "k8s.io/kubernetes/pkg/api/latest" </ins> "k8s.io/kubernetes/pkg/kubectl" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" )

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.
Change:
- hostPath: path: /var/log name: varlog <ins> - hostPath: path: /run name: run - hostPath: path: /run/xtables.lock name: iptableslock </ins>

Discussion:
BUG REPORT Kubernetes version 2 Environment: Install tools: What happened: The code in takes care to supply the flag so it will wait on a lock to avoid interference between multiple processes modifying the table. If you read the source you discover it does this by creating a file . However, when is running in a container, is in a local filesystem, so it is not able to lock against processes running on the host or in other containers. And before you decide that the answer is to mount from the host, look at all the issues around leaking netns, e.g. Credit for pointing this out to me. Credit for pointing out locking functionality was to a few months back
Ironically, this is caused by a bugfix that moved to file-based locking. Previously, iptables would lock by reserving an abstract unix socket, which is tied to the network namespace.
Some discussion also in and following comments.
I experimented with this: but it didn't work on CoreOS, as the host wasn't using a version of iptables that used the file lock yet. Just ended up creating a directory call
I guess I should file this as an issue against kubeadm and any of the other sources of kube-proxy container config.
/assign
Should we leave this open (waiting for ... ?)
Waiting for I guess... (which I'm reviewing now)
i think this should not be marked as complete until the kubeadm fixes are in.
/reopen
/close fix in
Change:
// the effects of previous updateFuncs to avoid potential conflicts. For example, if multiple // functions update the same field, updates in the last function are persisted. func (nim *nodeInfoManager) tryUpdateNode(updateFuncs ...nodeUpdateFunc) error { <ins> nim.lock.Lock() defer nim.lock.Unlock() </ins> // Retrieve the latest version of Node before attempting update, so that // existing changes are not overwritten.

Discussion:
What happened: I two CSI plugins to my Kubernetes cluster via a single call to . When I did this, the annotation was improperly set on 2 out of 3 nodes. Only one of the plugins appeared: What you expected to happen: Both and plugins should have appeared in the annotation. How to reproduce it (as minimally and precisely as possible): Apply two or more CSI plugins via a single call to . Anything else we need to know?: Kubelet logs indicate that it registered both plugins at the same time: The CSINode object looks complete: Only the node's annotation did not include Restarting kubelet fixed the issue. It looks like a race condition when InstallCSIDriver is called concurrently for multiple drivers. The code here: could lead to each thread observing the annotation as being empty, and then setting its own annotation that includes only itself. Environment: Kubernetes version (use ): v1.17.11 Cloud provider or hardware configuration: AWS OS (e.g: ): Ubuntu 20.04.1 LTS Kernel (e.g. ): Linux ip-172-31-17-163 5.4.0-1021-aws -Ubuntu SMP Fri Jul 24 09:42:29 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: juju
/sig storage
/assign
I can reproduce this issue with commands below ! The correct csi nodeid would be like this
Change:
if !(runtime.IsMissingVersion(err) || runtime.IsMissingKind(err) || runtime.IsNotRegisteredError(err)) { return nil, err } <ins> // Only tolerate load errors if the file appears to be one of the two legacy plugin configs unstructuredData := map[string]interface{}{} if err2 := yaml.Unmarshal(data, &unstructuredData); err2 != nil { return nil, err } _, isLegacyImagePolicy := unstructuredData["imagePolicy"] _, isLegacyPodNodeSelector := unstructuredData["podNodeSelectorPluginConfig"] if !isLegacyImagePolicy && !isLegacyPodNodeSelector { return nil, err } </ins> // convert the legacy format to the new admission control format // in order to preserve backwards compatibility, we set plugins that // previously read input from a non-versioned file configuration to the

Discussion:
/kind bug What happened: When I want to enable both plugins by passing below flag, as they both need config file, and I find I donot know what to set If I set , then I get an error in apiserver
/kind bug /sig auth
/cc
/cc
first, you can't put comments in json. the error was complaining about your embedded comments. this would let the server start: second, the docs are really, really, not right (opened with fixes). if you want to specify config for multiple plugins, should point to a config that references individual config files for each plugin (which there's a bug in loading... fixed in ): example
/assign
Change:
time.Sleep(10 * time.Millisecond) } <ins> count := reactor.getChangeCount() </ins> // Call the tested function err := test.test(ctrl, reactor, test) if err != nil { t.Errorf("Test %q initial test call failed: %v", test.name, err) } <del> reactor.waitTest() </del> <ins> for reactor.getChangeCount() < count+expectedChanges[ix] { reactor.waitTest() } </ins> evaluateTestResults(ctrl, reactor, test, t) }

Discussion:
Not many details in the logs: FAIL 2.721s
I ran tests a few times against recent master but couldn't see this, could it be an edgy case?
i'll look at it
should help a lot, still there will be a short window where the test could get wrong. Patch will follow when is merged.
Today I saw a very similar error to the one reported in , but seeing as that was closed as a dupe of this, adding details here:
this looks like something new. Let's keep this issue open for this unit test flake: I filled for integration test flake you reported.
Change:
Description: A Pod is created with liveness probe on grpc service. Liveness probe on this endpoint should fail because of wrong probe port. When liveness probe does  fail then the restart count should +1. */ <del> ginkgo.It("should be restarted with a GRPC liveness probe [NodeConformance]", func(ctx context.Context) { </del> <ins> framework.ConformanceIt("should be restarted with a GRPC liveness probe [NodeConformance]", func(ctx context.Context) { </ins> livenessProbe := &v1.Probe{ ProbeHandler: v1.ProbeHandler{ GRPC: &v1.GRPCAction{

Discussion:
Instructions: Tests in : should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe /sig node /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue KEP:
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 : Instructions: Tests in : /kind cleanup /priority important-soon /area tests /help-wanted /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 : Instructions: Tests in : /kind cleanup /priority important-soon /area tests /help-wanted /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
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
/assign
/assign
/assign
Hi, I want to take this
Change:
type ByImageSize []kubecontainer.Image func (a ByImageSize) Less(i, j int) bool { <ins> if a[i].Size == a[j].Size { return a[i].ID > a[j].ID } </ins> return a[i].Size > a[j].Size } func (a ByImageSize) Len() int      { return len(a) }

Discussion:
What happened: When two or more images on a given node have the same size, their order inside the field set by the process is not deterministic. This problem has the side effect of continually triggering controllers which assume this list to be always equal on node updates unless images are or removed. What you expected to happen: The order of images should be stable even when two images have the same size, using the image ID as a second sort field would help this. How to reproduce it (as minimally and precisely as possible): Choose a node and run: Run a few times: It should be possible to see and images alternating on the output. Anything else we need to know?: Our particular use case make it really common for multiple images to have the same size on a given node. I came across this problem while debugging slow updates to DaemonSets and finding out that the kube-controller-manager was leaking memory until it eventually dies due to OOM: <img width="800" alt="Screen Shot 2019-06-30 at 20 27 22" src="https://user-"I was able to track this leak to a large number of watched elements in memory and by taking a look at the logs with increased verbosity I figured it was due to too many Node notifications being processed by the DaemonSet controller: <img width="800" alt="Screen Shot 2019-06-30 at 20 36 23" src="https://user-"It's possible that other controllers in the wild that watch nodes and only ignore the conditions timestamps on updates to face the same problem. I'll send a simple PR to fix this shortly. Environment: Kubernetes version (use ): But by taking a look at the code this problem also happens on master.
/sig node
Nice debugging here :)
Change:
z/c	.	.	.	.	.	.	.	.	. */ <del> var _ = common.SIGDescribe("Netpol [LinuxOnly]", func() { </del> <ins> var _ = common.SIGDescribe("Netpol", func() { </ins> f := framework.NewDefaultFramework("netpol") ginkgo.Context("NetworkPolicy between server and client", func() {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.
Change:
// according to whatever system is managing the endpoint. A nil value // indicates an unknown state. In most cases consumers should interpret this // unknown state as ready. For compatibility reasons, ready should never be <del> // "true" for terminating endpoints. </del> <ins> // "true" for terminating endpoints, except when the normal readiness // behavior is being explicitly overridden, for example when the associated // Service has set the publishNotReadyAddresses flag. </ins> Ready *bool // serving is identical to ready except that it is set regardless of the

Discussion:
The EndpointSlice API says and it works as expected in normal circumstances I delete the pod and the endpoints conditions are the expected However, if during this time I set we run into an incoherence with the API doc, but it seems that we already documented this edge case in the code I think that at this point is just to amend this information to the API, no? /kind bug /kind documentation
/sig network /assign
I would like to work on this. I just want a bit more clarification on what needs to be done!
I proposed a solution, that is clarify it in the doc ... once we reach an agreement in this issue we implement it ...
+1 to docs. I'd make it a little more vague, like: """ when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag. """
so, the thing is to update the docs here with Tim's suggestion and here and do to update the generated code and submit a PR
/assign
I am not able to run command in windows, I am checking it. This error message is coming: *
/triage accepted
Is there a PR for this? Happy to review
I will raise the PR if my above problem gets solved. I am trying to make an update but the error mentioned above is coming.
What platform are you on? If the Makefile were really broken EVERYTHING would be failing.
he's on windows ... you will need a linux/macos. see
Let me know if you want someone to take it over.
I think in that case, you can assign this to someone else.
Change:
import ( "io/ioutil" <ins> "strings" </ins> "testing" "time" <del> "strings" </del> "github.com/davecgh/go-spew/spew" "k8s.io/apimachinery/pkg/api/meta"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : let's say I run If the deployment is comes up in time it tells me which deployment is up, but if it times out it doesn't tell me on which deployment/resource. Could it be Why is this needed: That would make it easier to use, and the information provided is the same irregardless on whether the condition is met or not
/sig cli
Sounds reasonable for me, i can take care of this one if someone from owners will approve it as a feature.
/assign Zyqsempai
GitHub didn't allow me to assign the following users: Zyqsempai. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Zyqsempai 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
Change:
corelisters "k8s.io/client-go/listers/core/v1" "k8s.io/klog" "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" <del> "k8s.io/kubernetes/pkg/scheduler/algorithm/priorities" </del> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" schedulerlisters "k8s.io/kubernetes/pkg/scheduler/listers"

Discussion:
/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help
Change:
if !s.IsUnschedulable() { return nil, diagnosis, s.AsError() } <ins> // All nodes in NodeToStatusMap will have the same status so that they can be handled in the preemption. // Some non trivial refactoring is needed to avoid this copy. for _, n := range allNodes { diagnosis.NodeToStatusMap[n.Node().Name] = s } </ins> // Record the messages from PreFilter in Diagnosis.PreFilterMsg. msg := s.Message() diagnosis.PreFilterMsg = msg

Discussion:
When PreFilter returns UnschedulableAndUnresolvable, we don't need to run the preemption, but currently we run. This unexpected preemption could cause errors from the preemption by trying to read non-exist PreFilter data. As pointed out (), actually we didn't run the preemption in such cases in the past versions, but introduced this bug. /kind bug /kind regression /sig scheduling /triage accepted /priority important-soon
/assign
will fix this.