jiebi/CodeConvo huggingface dataset:
Change:
add(t, dc.podStore, pod) dc.sync(ctx, pdbName) ps.VerifyNoStatusError(t, pdbName) <del> verifyUnsupportedControllerEventEmitted(t, dc) </del> <ins> verifyEventEmitted(t, dc, "UnmanagedPods") </ins> } // Check if the unmanaged pods are correctly collected or not

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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
Change:
} return ContainerStatus{} } <ins> // IsPodReady retruns true if a pod is ready; false otherwise. func IsPodReady(pod *Pod) bool { for _, c := range pod.Status.Conditions { if c.Type == PodReady && c.Status == ConditionTrue { return true } } return false } </ins>

Discussion:
I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil
Change:
}, }, { <ins> name: "pod cannot be scheduled as all nodes don't have label 'rack'", pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "rack", v1.DoNotSchedule, st.MakeLabelSelector().Exists("foo").Obj(), ).Obj(), nodes: []*v1.Node{ st.MakeNode().Name("node-a").Label("zone", "zone1").Label("node", "node-a").Obj(), st.MakeNode().Name("node-x").Label("zone", "zone2").Label("node", "node-x").Obj(), }, wantStatusCode: map[string]framework.Code{ "node-a": framework.UnschedulableAndUnresolvable, "node-x": framework.UnschedulableAndUnresolvable, }, }, { </ins> name: "pods spread across nodes as 2/1/0/3, only node-x fits", pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "node", v1.DoNotSchedule, st.MakeLabelSelector().Exists("foo").Obj(),

Discussion:
What happened: I was testing out the pod topology spread functionality in a local k8s cluster. I noticed that when I set the constraint to be pods are still successfully scheduled. What you expected to happen: Reading the documentation on , I expected pods not to be scheduled since the node should be "bypassed due to the absence of label". Did I miss something here? How to reproduce it (as minimally and precisely as possible): Create a pod with topologySpreadConstraints[0].topologyKey that does not match to any node labels, and set to . Anything else we need to know?: Thank you Environment: Kubernetes version (use ):Cloud provider or hardware configuration: It's a kind cluster created with image . OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
This sounds like a bug, I will look into it. /assign
Change:
assert.Contains(t, err.Error(), "unknown group version field") } <ins> func TestParsePolicyWithUnknownField(t *testing.T) { f, err := writePolicy(t, policyWithUnknownField) require.NoError(t, err) defer os.Remove(f) _, err = LoadPolicyFromFile(f) require.NoError(t, err) } </ins> func TestPolicyCntCheck(t *testing.T) { var testCases = []struct { caseName, policy string

Discussion:
Currently the [audit policy decoder][1] silently drops unknown fields. For backwards compatibility, we probably cannot fail on unknown fields, but it would be good to at least log a warning when they're encountered. [1]: /sig api-machinery
/triage accepted
/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 : /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
I'm not familiar with apiserver, but this seems like a simple one. /assign
How can we find unknown fields in the yaml file? Currently I'm think of converting both the yaml file and the decoded Policy struct to two map[string]interface{}, and compare both map to find out which keys are in the yaml file but not in the decoded struct, is there any better solution?
Courtesy on slack:
Change:
// Set up a wait for the first item's readyAt (if one exists) nextReadyAt := never if waitingForQueue.Len() > 0 { <ins> if nextReadyAtTimer != nil { nextReadyAtTimer.Stop() } </ins> entry := waitingForQueue.Peek().(*waitFor) <del> nextReadyAt = q.clock.After(entry.readyAt.Sub(now)) </del> <ins> nextReadyAtTimer = q.clock.NewTimer(entry.readyAt.Sub(now)) nextReadyAt = nextReadyAtTimer.C() </ins> } select {

Discussion:
Hi, We are experiencing a memory leak in our operator and it seems to be caused by some Timers: ! See here the original issue: After some investigations I found out that the can create a lot of timers (at least ) if the queue is not empty : The problem here is that if the event in the queue is to expire in a "far" future the previous timers will pile up and the memory will be reclaimed too late. Could someone confirm this scenario ? A fix would be to create some with and close them when they are not needed (e.g. is called) or superseded by a most recent one. Happy to discuss the issue and contribute if needed.
thanks for the report, moved to the main repo for better visibility /sig api-machinery
yes, using NewTimer would be better here
thanks for your feedback, could you assign me to this issue ? I will try to provide a fix.
Thanks, I have opened a PR:
Change:
# $5: pod name, which should be either etcd or etcd-events function prepare-etcd-manifest { local host_name=${ETCD_HOSTNAME:-$(hostname -s)} <del> local -r host_ip=$(python3 -c "import socket;print(socket.gethostbyname("${host_name}"))") </del> <ins> local -r host_ip=$(${PYTHON} -c "import socket;print(socket.gethostbyname("${host_name}"))") </ins> local etcd_cluster="" local cluster_state="new" local etcd_protocol="http"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gce-device-plugin-gpu Cluster up Apr 23 8:30PM PDT Taken from: From a , there are supposed to be three worker/minion nodes set up as well. Started failing after -- so maybe related to ? /cc /sig testing More examples of failing runs: /priority critical-urgent (this is a job on the release/master-blocking board)
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
It uses image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu as node image kubekins-e2e image is built from Base image is bootstrap image is built from with debian:buster and install python3.
The node image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu has no python3. We need to upgrade it.
Thanks for catching this and sending revert. Separately, we should definitely upgrade that image, cos-69 is super old and not supported anymore: /cc regarding GPU image
Change:
- Name: cpu Weight: 1 `), <del> wantErr: `decoding .profiles[0].pluginConfig[0]: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.resources[0].Name", unknown field "scoringStrategy.resources[0].Weight"`, </del> <ins> wantErr: `strict decoding error: decoding .profiles[0].pluginConfig[0]: strict decoding error: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.resources[0].Name", unknown field "scoringStrategy.resources[0].Weight"`, </ins> }, { name: "out-of-tree plugin args",

Discussion:
With the addition of server side validation in 1.23, it is now possible for a call to successfully decode it’s data and return a non-nil error when there are strict decoding errors (e.g. duplicate/unknown fields). This means that callers of can distinguish between fatal errors (that cause decoding to fail) and strict decoding errors (that still allow the decode to succeed) by inspecting the target object (to see if it was successfully decoded into) and the error itself (to see if it is a ) With the NestedObjectDecoder however, it only returns an error from giving no indication whether a strict decoding error it has returned comes from an internal decode step that short circuited (by not accounting for strict decoding errors) or actually did successfully decode, but also encountered strict decoding errors. We propose taking a few actions to minimize the possibility of erroneous short-circuiting from Document how all nested decoders should only return strict decoding errors if all decoding is successful or return only non-strict decoding (ie. fatal errors). Document this for all known in-tree and out-of-tree . Update in-tree nested decoders to do the above mentioned behavior (which is just the kube-scheduler) Long-term solutions to better guarantee that no erroneous short-circuiting is taking place could include deprecating the current interface in favor of one that returns both the target object that was decoded into along with an error return a special error type specific to indicating that all internal decoding was successful.
/sig api-machinery
/triage accepted
Change:
} // Check that ID list is correct. <del> ids := store.Contains() </del> <ins> ids := store.ContainedIDs() </ins> if !ids.HasAll("a", "c", "e") { t.Errorf("missing items") }

Discussion:
The client/cache interface has a method which is supposed to return a of the IDs in a store. This is a bit misleading and should probably be renamed to 'Contents' or 'ContainedIDs'.
Thoughts
I tend to agree. contains to me should always return a bool and take an input key. Sent from my iPhone
Yeah, I agree, both of the suggested names would be an improvement.
Change:
return nil } <ins> func getSCSIControllersOfType(vmDevices object.VirtualDeviceList, scsiType string) []*types.VirtualController { // get virtual scsi controllers of passed argument type var scsiControllers []*types.VirtualController for _, device := range vmDevices { devType := vmDevices.Type(device) if devType == scsiType { if c, ok := device.(types.BaseVirtualController); ok { scsiControllers = append(scsiControllers, c.GetVirtualController()) } } } return scsiControllers } func getSCSIControllers(vmDevices object.VirtualDeviceList) []*types.VirtualController { // get all virtual scsi controllers var scsiControllers []*types.VirtualController for _, device := range vmDevices { devType := vmDevices.Type(device) switch devType { case SCSIControllerType, LSILogicControllerType, BusLogicControllerType, PVSCSIControllerType, LSILogicSASControllerType: if c, ok := device.(types.BaseVirtualController); ok { scsiControllers = append(scsiControllers, c.GetVirtualController()) } } } return scsiControllers } func getAvailableSCSIController(scsiControllers []*types.VirtualController) *types.VirtualController { // get SCSI controller which has space for adding more devices for _, controller := range scsiControllers { if len(controller.Device) < SCSIControllerDeviceLimit { return controller } } return nil } </ins> func getVirtualDiskUUID(newDevice types.BaseVirtualDevice) (string, error) { vd := newDevice.GetVirtualDevice()

Discussion:
vSphere cloud provider volume plugin attach disk limits the number of volumes because of two issues: new SCSI controller is only created when one does not exist. A new controller should be when required and limit not reached. disk will fail when attaching disk to slot 7 on controller. Slot 7 on SCSI controller is reserved and therefore should be skipped. This issue has been brought up in Govmomi library .
Change:
// The Kubelet will look in this directory for an init configuration. // The path may be absolute or relative; relative paths are under the Kubelet's current working directory. // Omit this flag to use the combination of built-in default configuration values and flags. <del> // To use this flag, the DynamicKubeletConfig feature gate must be enabled. </del> <ins> // To use this flag, the KubeletConfigFile feature gate must be enabled. </ins> InitConfigDir flag.StringFlag // EXPERIMENTAL FLAGS

Discussion:
See:
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
For some reason GitHub didn't close this automatically when the referencing PR merged.
Change:
for attempts := 0; attempts < 4; attempts++ { outputBytes, err = exec.Command("gcloud", "compute", "addresses", "create", name, "--project", TestContext.CloudConfig.ProjectID, <del> "--region", region, "-q").CombinedOutput() </del> <ins> "--region", region, "-q", "--format=yaml").CombinedOutput() </ins> if err == nil { break }

Discussion:
5 tests failed, 6 jobs failed, 151 builds failed. Failure stats cover 1 day time range '2 Jun 2017 20:57 UTC' to '3 Jun 2017 20:57 UTC'. <details<summaryRationale for assignments:</summary </details<br
/unassign I am probably not the right owner for these tests. Leaving this to to triage it.
This seems pretty likely a quota issue. Many of them started after the cleanuped the old gce resources. Probably some tests are leaking resources. Though it doesn't occur on other CIs like . I will dig into it a bit more.
The root cause is ~2 years old from We are parsing human readable gcloud output, which recently changed. Additionally, when we fail to create the LB we leak the static IP address. It's failing on GKE but not GCE because GKE uses a pre-release version of gcloud as a canary.
/priority failing-test
/reopen ci-kubernetes-e2e-gci-gke-slow-release-1.5 and ci-kubernetes-e2e-gke-slow-release-1.5 will continue failing until we cherry pick the fix. Reopen for now.
Forgot to update: ci-kubernetes-e2e-gci-gke-slow starts passing after was merged.
Can you cherrypick to both 1.5 and 1.6 branch? But this issue is not 1.7 blocking issue anymore.
Sure, working on it.
Sent cherry picks: release-1.6: release-1.5: release-1.4: Cherrypicking the fix into 1.4 as well because we also have gce-slow-1.4 and gci-slow-1.4 CIs running.
remove the milestone, this is not a 1.7 issue
Since all issues listed here are addressed separately. Close this one.
Change:
expectedNodeCondition := v1.NodeDiskPressure expectedStarvedResource := v1.ResourceEphemeralStorage pressureTimeout := 10 * time.Minute <ins> highPriorityClassName := f.BaseName + "-high-priority" highPriority := int32(999999999) BeforeEach(func() { _, err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Create(&schedulerapi.PriorityClass{ObjectMeta: metav1.ObjectMeta{Name: highPriorityClassName}, Value: highPriority}) Expect(err == nil || errors.IsAlreadyExists(err)).To(BeTrue()) }) AfterEach(func() { err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Delete(highPriorityClassName, &metav1.DeleteOptions{}) Expect(err).NotTo(HaveOccurred()) }) </ins> Context(fmt.Sprintf(testContextFmt, expectedNodeCondition), func() { tempSetCurrentKubeletConfig(f, func(initialConfig *kubeletconfig.KubeletConfiguration) { initialConfig.FeatureGates[string(features.PodPriority)] = true

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
ObjectMeta: metav1.ObjectMeta{Name: saRolePrefix + "ephemeral-volume-controller"}, Rules: []rbacv1.PolicyRule{ rbacv1helpers.NewRule("get", "list", "watch").Groups(legacyGroup).Resources("pods").RuleOrDie(), <ins> rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("pods/finalizers").RuleOrDie(), </ins> rbacv1helpers.NewRule("get", "list", "watch", "create").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie(), eventsRule(), },

Discussion:
This test fails when OwnerReferencesPermissionEnforcement admission plugin is enabled: After the test creates a pod with an ephemeral volume, ephemeral volume controller in kube-controller-manager fails to create a PVC for it: The controller must have permissions to to be allowed to set with to Pods. The test passes. With : ENABLEADMISSIONPLUGINS="NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,Priority,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,OwnerReferencesPermissionEnforcement" ALLOWPRIVILEGED=true LOGLEVEL=4 hack/local-up- Kubernetes version (use ): 1.21.0 & today's master
/sig storage /triage accepted /priority important-soon