jiebi/CodeConvo huggingface dataset:
Change:
if evaluator == nil { listerFunc := generic.ListerFuncForResourceFunc(qm.informerFactory.ForResource) listResourceFunc := generic.ListResourceUsingListerFunc(listerFunc, resource) <del> evaluator = generic.NewObjectCountEvaluator(false, resource.GroupResource(), listResourceFunc, "") </del> <ins> evaluator = generic.NewObjectCountEvaluator(resource.GroupResource(), listResourceFunc, "") </ins> qm.registry.Add(evaluator) glog.Infof("QuotaMonitor created object count evaluator for %s", resource.GroupResource()) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig api-machinery What happened: The that we use to make a create validation function is given admission.Update as its operation field. In the create validation we then use the provided operation (admission.Update) , when we call the admission controllers, even though a new object is being created. A similar thing is happening with the mutating admission. This means that when an objects is created on update, the admission controllers will see this as an update request. Meaning there could be an objects in storage which never passed create admission validation and were never modified by create admission mutation. I think this is a bug. What you expected to happen: Admission controllers would handle a create-on-update exactly the same as a normal create
I think the solution to this would be to separate the static admission attributes into one for the create validation and one for the update validation. Also, the function which performs the mutating admission needs to determine whether or not it is an actual update or if the old object doesn't exist (probably by checking uid) and then call the mutating admission correctly based on which operation is being performed.
/assign I might be interested to give it a try.
How to reproduce this bug?
Instead of a reproduceable BUG, I think it's like a mismatch of conceptual design and actual implementation. If a resource allows create-on-update in its strategy e.g.: Then admission plugins would receive operations (CREATE/UPDATE) on UPDATE requests. Some problems might happen the admission plugin is written without considering the circumstances that admitting a UPDATE operation might result a object creation into the storage. Risky and confusing, WDYT?
With the current build in admission controllers, I'm not sure if there are any bugs. Maybe something with resource quota? The real problem is that there is no way to know which webhook authors will have a dependency on seeing a "create" operation for every object put into storage. If a webhook relies on creates to implement its custom logic (which should be allowed), then objects created with an update would currently be missed by the webhook.
Change:
"net.ipv4.ip_unprivileged_port_start", "net.ipv4.ip_local_reserved_ports", "net.ipv4.tcp_keepalive_time", <ins> "net.ipv4.tcp_fin_timeout", "net.ipv4.tcp_keepalive_intvl", "net.ipv4.tcp_keepalive_probes", </ins> ) )

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
able to start with Secret and ConfigMap volumes mounted into the container. release: v1.13 file: test/e2e/storage/empty_dir_wrapper.go <ins> - testname: PersistentVolumes(Claims), lifecycle codename: '[sig-storage] PersistentVolumes CSI Conformance should run through the lifecycle of a PV and a PVC [Conformance]' description: Creating PV and PVC MUST succeed. Listing PVs with a labelSelector MUST succeed. Listing PVCs in a namespace MUST succeed. Patching a PV MUST succeed with its new label found. Patching a PVC MUST succeed with its new label found. Reading a PV and PVC MUST succeed with required UID retrieved. Deleting a PVC and PV MUST succeed and it MUST be confirmed. Replacement PV and PVC MUST be created. Updating a PV MUST succeed with its new label found. Updating a PVC MUST succeed with its new label found. Deleting the PVC and PV via deleteCollection MUST succeed and it MUST be confirmed. release: v1.29 file: test/e2e/storage/persistent_volumes.go </ins> - testname: Projected Volume, multiple projections codename: '[sig-storage] Projected combined should project all components that make up the projection API [Projection][NodeConformance] [Conformance]'

Discussion:
[X] test approval issue : [X] test pr : 26 May 2023 [x] two weeks soak end date : 9 June 2023 [x] test promotion pr : [x] remove endpoint from [x] End of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. According to following APIsnoop query, there are still 3 CSIDriver endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 3 endpoints. The e2e logs for this test are listed below. This query shows the following csiDriver 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 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection.
Reopened this issue. <detailsIn response to : /reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. 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 volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.SplitUniqueName failed", err) } attachableVolumePlugin, err = og.volumePluginMgr.FindAttachablePluginByName(pluginName) <del> if err != nil { return volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.FindAttachablePluginBySpec failed", err) </del> <ins> if err != nil || attachableVolumePlugin == nil { return volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.FindAttachablePluginByName failed", err) </ins> } }

Discussion:
What happened: During investigation of nil pointer dereference panic, i've found that has an issue: don't check 1st return value of to : but could return : So, if finds plugin by name, but this plugin isn't a , it will cause a nil pointer dereference panic in What you expected to happen: should check How to reproduce it (as minimally and precisely as possible): Unfortunately, i can't reproduce it Anything else we need to know?: advised to change signature to <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig storage
how often have you run in to this? can you help put together a fix?
We could fix this but IMO this should never be reproducible because this panic will only happen if function finds a plugin but the plugin is not attachable. This could never happen because we only initialize attachable volume plugins in attach/detach controller and hence will ALWAYS return error because it will not be able to find a non-attachable plugin with that name.
Yes that makes sense. We need more info from Also do you have any modification or are you running a standard k8s?
it could be argued that - we should still fix this for sake for clarity. I will do that post 1.13. /assign
I've sent a PR to fix this issue: We it in about 30 minutes during rolling update, and, unfortunately, we're unable to reproduce it. It was k8s with modified apiserver & kubelet, but there was no modifications in kube-controller-manager. Panic trace:
Change:
if err != nil { t.Errorf("%v: error %v (%#v)n", test, err, err) } <del> if test != lq.String() { </del> <ins> if strings.Replace(test, " ", "", -1) != lq.String() { </ins> t.Errorf("%v restring gave: %vn", test, lq.String()) } }

Discussion:
When polling a k8s master with the response is an HTTP 500. But even if this selector is invalid, it should return a 4xx code instead.
Do you get 500 without the label selector? cc
No, and not with a value like "environment%3Dfoobar". But if I remove "foobar" or replace it with an url-encoded space, i.e. "environment%3D%20" or "environment%3D+" I get a 500. I suspect that the value (after the colon) is stripped of whitespace, and if the result is the empty string, this error happens.
Bumping priority to P1 since this is definitely a bug and we should fix it.
you had five days, I'm kicking you off of this & giving to Chao. :)
Change:
return cmdutil.AddSourceToErr("creating", info.Source, err) } <del> if cmdutil.ShouldRecord(cmd, info) { if err := cmdutil.RecordChangeCause(info.Object, f.Command(cmd, false)); err != nil { return cmdutil.AddSourceToErr("creating", info.Source, err) } } </del> if !dryRun { // Then create the resource and skip the three-way merge if err := createAndRefresh(info); err != nil {

Discussion:
What happened: What you expected to happen: DS history revision 2 should have change cause from the second command "kubectl apply -f ds-2.yaml --record", not the first /assign
Change:
COPY peer-finder / # See README.md <del> RUN wget -q -O /zookeeper-3.5.0-alpha.tar.gz http://apache.mirrors.pair.com/zookeeper/zookeeper-3.5.0-alpha/zookeeper-3.5.0-alpha.tar.gz &&  </del> <ins> RUN wget -q -O /zookeeper-3.5.0-alpha.tar.gz http://archive.apache.org/dist/zookeeper/zookeeper-3.5.0-alpha/zookeeper-3.5.0-alpha.tar.gz &&  </ins> tar -xzf /zookeeper-3.5.0-alpha.tar.gz -C /tmp/ && mv /tmp/zookeeper-3.5.0-alpha /zookeeper && rm /zookeeper-3.5.0-alpha.tar.gz ADD install.sh /

Discussion:
/kind bug What happened: The test image pets/zookeeper-installer references an old alpha version of zookeeper: This can't be built anymore, as it no longer exists on the server: Sure enough, now lists beta versions for 3.5.x, as well as stable 3.4.x versions, but no 3.5.0 alphas. We probably should update this to a newer version, or alternately delete the test and image if it's no longer providing signal. How to reproduce it (as minimally and precisely as possible): /sig apps
Change:
attach, err := c.k8s.StorageV1beta1().VolumeAttachments().Get(attachID, meta.GetOptions{}) if err != nil { glog.Error(log("attacher.WaitForAttach failed for volume [%s] (will continue to try): %v", volumeHandle, err)) <del> return "", err </del> <ins> return "", fmt.Errorf("volume %v has GET error for volume attachment %v: %v", volumeHandle, attachID, err) </ins> } // if being deleted, fail fast if attach.GetDeletionTimestamp() != nil {

Discussion:
brought this up during the CSI Standup. It seems to be true, in the test config we do not set which is required to bring up the pod for consuming the volume. The code where is checked: The test config used where is not set to true: /kind bug /sig storage /assign /cc
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/client-go/pkg/api/v1" <ins> appsv1beta1 "k8s.io/client-go/pkg/apis/apps/v1beta1" </ins> ) // describes the attributes of a scale subresource

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
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
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?
Change:
- --namespace=kube-system - --configmap=kube-dns-autoscaler # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base <del> - --target=Deployment/kube-dns </del> <ins> - --target={{.Target}} </ins> # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. # If using small nodes, "nodesPerReplica" should dominate. - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true}}

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
// SetGroupVersionKind sets or clears the intended serialized kind of an object. Passing kind nil // should clear the current setting. SetGroupVersionKind(kind GroupVersionKind) <del> // GroupVersionKind returns the stored group, version, and kind of an object, or nil if the object does // not expose or provide these fields. </del> <ins> // GroupVersionKind returns the stored group, version, and kind of an object, or an empty struct // if the object does not expose or provide these fields. </ins> GroupVersionKind() GroupVersionKind }

Discussion:
The statement "returns [...], or nil" cannot be true since the return type is a struct: Suggest it could say ", or an empty struct if ..." /sig api-machinery
I can file a PR to fix the incorrect comment if you don't mind :)
Sure, I didn't get round to it yet.
/assign
Change:
type RollingUpdateDeployment struct { // The maximum number of pods that can be unavailable during the update. // Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). <del> // Absolute number is calculated from percentage by rounding up. </del> <ins> // Absolute number is calculated from percentage by rounding down. </ins> // This can not be 0 if MaxSurge is 0. // By default, a fixed value of 1 is used. // Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
--tags "${NODE_TAG}"  ${network}  $(get-scope-flags)  <del> --metadata-from-file "$(get-linux-node-instance-metadata-from-file)" </del> <ins> --metadata-from-file "$(get-node-instance-metadata-from-file)" </ins> } # Assumes:

Discussion:
<!-- 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 gce cluster creation script fails, when HEAPSTERMACHINETYPE env variable is provided. The script calls What you expected to happen: Script shouldn't fail. How to reproduce it (as minimally and precisely as possible): Run hack script to setup the cluster. Anything else we need to know?: Tis bug was introduced in This problem is due to call to not existing function - get-linux-node-instance-metadata-from-file": Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Linux Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Will be fixed by
Change:
// mountPropagation determines how mounts are propagated from the host // to container and the other way around. // When not set, MountPropagationHostToContainer is used. <del> // This field is alpha in 1.8 and can be reworked or removed in a future // release. </del> <ins> // This field is beta in 1.10. </ins> // +optional optional string mountPropagation = 5; }

Discussion:
<!-- 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: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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 push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
NoDiskConflictPred = "NoDiskConflict" // PodToleratesNodeTaintsPred defines the name of predicate PodToleratesNodeTaints. PodToleratesNodeTaintsPred = "PodToleratesNodeTaints" <ins> // CheckNodeUnschedulablePred defines the name of predicate CheckNodeUnschedulablePredicate. CheckNodeUnschedulablePred = "CheckNodeUnschedulable" </ins> // PodToleratesNodeNoExecuteTaintsPred defines the name of predicate PodToleratesNodeNoExecuteTaints. PodToleratesNodeNoExecuteTaintsPred = "PodToleratesNodeNoExecuteTaints" // CheckNodeLabelPresencePred defines the name of predicate CheckNodeLabelPresence.

Discussion:
DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by