jiebi/CodeConvo huggingface dataset:
Change:
utilsysctl.VmPanicOnOOM:       utilsysctl.VmPanicOnOOMInvokeOOMKiller, utilsysctl.KernelPanic:        utilsysctl.KernelPanicRebootTimeout, utilsysctl.KernelPanicOnOops:  utilsysctl.KernelPanicOnOopsAlways, <ins> utilsysctl.RootMaxKeys:        utilsysctl.RootMaxKeysSetting, utilsysctl.RootMaxBytes:       utilsysctl.RootMaxBytesSetting, </ins> } sysctl := utilsysctl.New()

Discussion:
Forked from To make debian-based node compatible with docker 1.11.X, I updated both /proc/sys/kernel/keys/rootmaxkey and /proc/sys/kernel/keys/rootmaxbytes. Also other kubernetes components do the similar thing. For example, kube_proxy: We should clean up those configurations into one common place.
cc/
Is this looking for an owner? It seems the ask is to generalize these types of settings in a module.
Yeah. We update quite a few kernel settings in kubelet itself. We should move the ones mentioned in this issue to kubelet if it is applicable to other distros too. want to own this?
Sure, I'll start poking.
Test results so far for a few distributions' default settings Operating SystemValue --- --- Debian Jessie 8.7.5200 --- --- --- Ubuntu 14. --- --- --- Ubuntu 16. --- --- --- CentOS --- --- --- Fedora --- --- --- Redhat Atomic --- --- --- CoreOS stable1000000 --- --- undefined --- undefined
Change:
// Pre-fetch all images tests depend on so that we don't fail in an actual test func PrePullAllImages() error { for _, image := range ImageRegistry { <del> output, err := exec.Command("docker", "pull", image).CombinedOutput() </del> <ins> var ( err    error output []byte ) for i := maxImagePullRetries; i > 0; i++ { if output, err = exec.Command("docker", "pull", image).CombinedOutput(); err == nil { break } time.Sleep(imagePullRetryDelay) } </ins> if err != nil { glog.Warningf("Could not pre-pull image %s %v output:  %s", image, err, output) return err

Discussion:
Another image pull related failure: Looking at the docker logs, it looks like docker is getting a 404 pulling some of the images
The error message looks normal. Kubelet always inspects to check whether the image is present before pulling image. If the image is not present, docker will record 404 error in log. However, the wired thing is that, if we've already prepull images, the image should be present. :)
The logs are from May 2nd, when we didn't have the image prepulling. Closing the issue.
Change:
// Matches the analytics blurb, with or without the munge headers. analyticsRE = regexp.MustCompile(`[n]*` + analyticsExp + `[n]?` + <del> `|` + `[n]*` + beginMungeExp + `[^<]*` + endMungeExp + `[n]*`) </del> <ins> `|` + `[n]*` + beginMungeExp + `[^<]*` + endMungeExp) </ins> ) // This adds the analytics link to every .md file.

Discussion:
If you try mimicking the release flow for a release on right now, it's busted: If I generate a dummy commit out of that failure, then run to see what gets generated, it's attempting to actually add the unversioned warnings back in: I was trying to write up a PR to enact something for , but this blocks the release piece for that. Which is fine, we have some time.
cc
Running gendocs should add the unversioned warnings, unless the doc has <!-- TAG IS_VERSIONED --. Do you know if mark-new-version that tag before failing?
Ah, I think I see what might be happening. This is the post- version of Notice the newline fun.
Sorry which newline are you talking about? :)
My PR fixes that
Ah, yes, cool. It would help if you flagged functional changes along more loudly. :)
Yea, sorry about that. Have updated the PR description to highlight each fix.
Change:
if pod.DeletionTimestamp != nil || pod.Status.Phase == v1.PodFailed { continue } <ins> // Pending pods are ignored. if pod.Status.Phase == v1.PodPending { ignoredPods.Insert(pod.Name) continue } // Pods missing metrics. </ins> metric, found := metrics[pod.Name] if !found { missingPods.Insert(pod.Name) continue } <ins> // Unready pods are ignored. </ins> if resource == v1.ResourceCPU { var ignorePod bool _, condition := podutil.GetPodCondition(&pod.Status, v1.PodReady)

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! If the matter is security related, please disclose it privately via --What happened: When the HPA scales up beyond the capacity of the cluster, many unscheduled pods are created. When load is removed, the usage ratio drops and the HPA tries to scale down. The unscheduled pods do not produce metrics, so the HPA fills in the 100% usage and re-evaluates the usage ratio. Because of the many fake 100% metrics, the new usage ratio is above the target value and the direction of scale is reversed. In this case, the HPA decides not to make any change to the current scale. What you expected to happen: I would expect the HPA to not get stuck when load is removed. How to reproduce it (as minimally and precisely as possible): and put it under load in a cluster without cluster autoscaling. the Deployment to increase the CPU request beyond the capability of the cluster (e.g. 500m). This should produce many Pending pods. load. The Pending pods will keep the HPA scaled indefinitely. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.9-gke.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T21:30:53Z", GoVersion:"go1.10.8b4", Compiler:"gc", Platform:"linux/amd64"} 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 autoscaling
This might Previous I suspected that this was the same issues as (HPA positive feedback loop).

However it turns out to be different, that Pending pods cause HPA to get stuck.
Original reason for using 100% utilization for missing metrics when scaling down:
Change:
current := 0 same := 0 <del> defer func() { By("Cleaning up the replication controller") err := DeleteRC(c, ns, name) Expect(err).NotTo(HaveOccurred()) }() </del> By(fmt.Sprintf("Creating replication controller %s", name)) _, err := c.ReplicationControllers(ns).Create(&api.ReplicationController{ ObjectMeta: api.ObjectMeta{

Discussion:
Currently the density tests are ok if all the pods come up eventually. We should verify there are no failure/error events while the pods are coming up. This could indicate issues dealing with the number of pods and should be investigated.
has been merged, and there's already an issue filed for followup actions, so I think we can close this.
Change:
CROSS_BUILD_COPY qemu-QEMUARCH-static /usr/bin/ RUN apk add --no-cache bind-tools dnsmasq <ins> ADD https://github.com/coredns/coredns/releases/download/v1.5.0/coredns_1.5.0_linux_BASEARCH.tgz /coredns.tgz RUN tar -xzvf /coredns.tgz && rm -f /coredns.tgz </ins>

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: should support configurable pod Since when has it been failing: N/A Testgrid link: N/A Reason for failure: Since ` was used instead. Anything else we need to know: /sig testing /sig windows
Change:
} func (plugin *execNetworkPlugin) validate() error { <del> if syscall.Access(plugin.getExecutable(), X_OK) != nil { </del> <ins> if !isExecutable(plugin.getExecutable()) { </ins> errStr := fmt.Sprintf("Invalid exec plugin. Executable '%s' does not have correct permissions.", plugin.execName) return errors.New(errStr) }

Discussion:
/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<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
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc
Change:
metrics.FrameworkExtensionPointDuration.WithLabelValues(metrics.Score, status.Code().String(), f.profileName).Observe(metrics.SinceInSeconds(startTime)) }() allNodePluginScores := make([]framework.NodePluginScores, len(nodes)) <del> numPlugins := len(f.scorePlugins) - state.SkipScorePlugins.Len() </del> <ins> numPlugins := len(f.scorePlugins) </ins> plugins := make([]framework.ScorePlugin, 0, numPlugins) pluginToNodeScores := make(map[string]framework.NodeScoreList, numPlugins) for _, pl := range f.scorePlugins {

Discussion:
When initializing kube-scheduler, We provided a custom config file for KubeSchedulerConfiguration and disabled the score plugin. This resulted in a panic in kube-scheduler at kube-scheduler up and running Using the below KubeSchedulerConfiguration file to enable kube-scheduler. apiVersion: kind: KubeSchedulerConfiguration clientConnection: kubeconfig: profiles: plugins: score: disabled: name: '*' extenders: urlPrefix: https://127.0.0.1:/scheduler filterVerb: "predicates" weight: 1 httpTimeout: 60s enableHTTPS: true nodeCacheCapable: false ignorable: false While trying to debug the issue, I found a change done recently for preScore calculation which might be causing the issue When we disable only the Score plugin then scheduler configuration will result in default preScorePlugins with 3 enabled [NodeResourcesFit, InterPodAffinity, TaintToleration] And due to this change, the preScore for InterPodAffinity results in skip status for some case (still not able to figured out what exactly it is), and this might result in a panic for kube-scheduler. The numplugin variable turns out to be negative. 28.3 N/A No response kubeadm No response No response
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
Let me take a look.
/assign
maybe related to
Past me argued this in the PR
scheduler-plugins' integration test also hits this: To end-users: if the fix () or its cherrypicks are not around in your k8s cluster. The workaround is that when disabling Score plugins, ensure to disable their PreScore counterparts as well.
Change:
func (o *createClusterOptions) complete(cmd *cobra.Command) error { args := cmd.Flags().Args() if len(args) != 1 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", args) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", args) </ins> } o.name = args[0]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
// String is the method to format the flag's value, part of the flag.Value interface. func (c *cidrs) String() string { <del> return strings.Join(c.ipn.StringSlice(), ",") </del> <ins> s := c.ipn.StringSlice() sort.Strings(s) return strings.Join(s, ",") </ins> } // Set supports a value of CSV or the flag repeated multiple times

Discussion:
/kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related 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
Change:
if len(v) > 0 { out, err := b.exec.Run("iscsiadm", "-m", "node", "-p", tp, "-T", b.Iqn, "-I", b.Iface, "-o", "update", "-n", k, "-v", v) if err != nil { <del> return fmt.Errorf("iscsi: failed to update node session key %q with value %q error: %v", k, v, string(out)) </del> <ins> return fmt.Errorf("iscsi: failed to update node session key %q error: %v", k, string(out)) </ins> } } }

Discussion:
This issue was reported in the Description Kubernetes can be configured to use iSCSI volumes. When using CHAP authentication, CHAP secrets are stored using the Secrets API, such as in this . When a pod is configured to use iSCSI and the AttachDisk method is called, this will call the code in Figure 1. Figure 19.1: iSCSI secret handling These two functions both iterate over a slice of strings that are keys that reference secrets in a map. These are then used to generate iscsiadm commands. As shown, if there are errors in executing these commands, errors are returned with both the key and secret values in the error string. These errors will eventually be logged using klog: Someone with access to these logs would be able to view the sensitive secrets and could potentially gain access to iSCSI volumes. Exploit Scenario Alice runs a cluster, and wishes to use iSCSI for data storage. Eve has access sufficient to collect the logs, and uses this access to connect to iSCSI storage devices as a privileged user. Recommendation Short term, as in TOB-K8S-001: Bearer tokens revealed in logs, do not log sensitive credentials at any logging level, as they may accidentally leak into inappropriate environments, such as production. Long term, implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to reification within logs. In either case, ensure that sensitive data cannot be stored in logs. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-003 and it was finding 22 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 61 of the Environment: Kubernetes version: 1.13.4
/sig storage /area security /kind bug /remove-kind feature
Change:
<del> #!/bin/bash # Copyright 2014 Google Inc. 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. function detect-master () { echo "Running locally" } </del>

Discussion:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.
Change:
} var err error <ins> var output string </ins> podName := g.kubeControllerManager g.waitForControllerManagerReadyOnce.Do(func() { if readyErr := e2epod.WaitForPodsReady(g.client, metav1.NamespaceSystem, podName, 0); readyErr != nil {

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig instrumentation /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The flake happened in before.
This is fixed. !
/reopen This is still failing. Sample run:
Reopened this issue. <detailsIn response to : /reopen Sample run: 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
/priority critical-urgent
The error message in makes me think the apiserver is not available during that test run: . Can someone link to the frequency graphs to see if the problem is widespread?
got it:
I don't think I was right above. I think the "the server is currently unable to handle the request" is an error coming from the proxy. The proxy was around the time this issue was filed (), so it seems likely to be related to it. can you take a look?
This is a known issue, and is working on it . Now that is being blocked by the debugging handler problem, could we merge to mitigate this problem first? cc
I would prefer to reach a decision about enabling the debug handlers, but if that's not possible, then merging PR as mitigation might make sense.
Think I hit this also.
It appears to still be failing based on
Why rebase? Any new test run will be based on merge with current k/k master and thus contain
<img width="1111" alt="Screen Shot 2021-05-28 at 13 04 52" src="https://user-" looks like it has become more stable now.
/close
Closing this issue. <detailsIn response to : /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:
{ Name:  "etcd", Image: etcdImage, <ins> Command: []string{ "/usr/local/bin/etcd", }, </ins> }, } d := &apps.Deployment{

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! If the matter is security related, please disclose it privately via --What happened: I see only amd64 architecture etcd is used for the which will create issues for the other architectures like ppc64le, arm etc. We need to replace this etcd image with the k8s maintained fat manifest image present in
/sig testing
Change:
apipod "k8s.io/kubernetes/pkg/api/v1/pod" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/scheduler/framework" <ins> "k8s.io/kubernetes/pkg/scheduler/framework/parallelize" </ins> "k8s.io/kubernetes/pkg/scheduler/metrics" "k8s.io/kubernetes/pkg/scheduler/util" )

Discussion:
When a pod requires preempting more than one pod, this happens sequentially. It should be done in parallel. /sig scheduling /sig scalability Preemption happens in the scheduling cycle, meaning that no other scheduling attempts happen while preemption is ongoing, hurting throughput. An alternative is to the deletes in a separate routine, like we do for binding.
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
cc
I'm a newbie, may I have a try at this proposal?
Yes, this is a good candidate for new contributors. However, I would like to hear from SIG scalability whether there are any concerns about this.
Parallelizing the loops looks like the easier option to implement, but deleting in a separate routine will likely offer the better throughput for the average case.
Parallelizing loops seems fine from SIG Scalability perspective - we already do something similar for example in KCM when creating pods or in scheduler each binding is done by separate goroutine. One question though, is there a limit of pods that we want to preempt here? 100 parallel calls will be probably fine, but 1000 wouldn't be most likely.
We only preempt pods from a single node, so that's a natural threshold. And we have a parallelizing mini-library that has 16 workers by default.
Hi, do you still want to work on this one?
YesIt's still under discussion.
So we can use the parallelizing mini-library to do this?
You can use this parallelizer we defined in scheduler framework directly.
feel free to take it by writing on a comment.
/assign