jiebi/CodeConvo huggingface dataset:
Code change:
"pod", klog.KObj(ps.pod)) continue } <del> if now.After(*ps.deadline) { </del> <ins> if cache.ttl != 0 && now.After(*ps.deadline) { </ins> klog.InfoS("Pod expired", "pod", klog.KObj(ps.pod)) if err := cache.removePod(ps.pod); err != nil { klog.ErrorS(err, "ExpirePod failed", "pod", klog.KObj(ps.pod))

Related discussion:
text: I would like to take this task
Plz assign to yourself to notify that you"re working on this.
/assign
/assign
done. thanks!
/assign
Could you please guide for this Issue are you suggesting we should not check cache before assigning the pod and need other way around?
FTR, I'm considering assigned to this issue, as they were the first to get assigned. You can see that in we increased the timeout. We want to get rid of the timeout. Then, we can just get rid of the logic that uses the timeout to remove some pods from the cache.
/reopen We still need to remove the code in 1.27
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
/assign
/unassign
one more release before we can remove this code.
do you have plan to cherry pick for previous versions, e.g 1.23, 1.24?
did you mean 1.13 and 1.14?
oh, sorry my bad, I meant for 1.23 and 1.24
It is fixed in 1.23 , so it would be fixed in 1.24 too.
my understanding is the previous fix to increase the duration only reduce the chance of issue, but not completely avoid it, that's why the other 2 fixes and are needed, right?
Hi, is this issue still available?
yes, but since the likelihood that an issue happens is very low, I don't think it's worth the risk of cherry-picking at this point.
According to , we can remove the TTL code entirely in 1.27 I'll give the chance to to confirm if they can still do this. In the meantime: /unassign /unassign /remove-help
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
Code change:
"pod", klog.KObj(ps.pod)) continue } <del> if now.After(*ps.deadline) { </del> <ins> if cache.ttl != 0 && now.After(*ps.deadline) { </ins> klog.InfoS("Pod expired", "pod", klog.KObj(ps.pod)) if err := cache.removePod(ps.pod); err != nil { klog.ErrorS(err, "ExpirePod failed", "pod", klog.KObj(ps.pod))

Related discussion:
text: This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /unassign as we haven't heard from them.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
I want to help fix this /assign
Thanks. What is left is to remove the timeout logic altogether.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned".
Code change:
"pod", klog.KObj(ps.pod)) continue } <del> if now.After(*ps.deadline) { </del> <ins> if cache.ttl != 0 && now.After(*ps.deadline) { </ins> klog.InfoS("Pod expired", "pod", klog.KObj(ps.pod)) if err := cache.removePod(ps.pod); err != nil { klog.ErrorS(err, "ExpirePod failed", "pod", klog.KObj(ps.pod))

Related discussion:
text: <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen remove the expire logic
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen remove the expire logic Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I think we can leave this closed. Entirely removing the timeouts has proven to be close to impossible without introducing regressions. We might need a few more iterations. Maybe we can reconsider when scheduling hints graduates to Stable.
Code change:
"create_clusterrole.go", "create_clusterrolebinding.go", "create_configmap.go", <ins> "create_cronjob.go", </ins> "create_deployment.go", "create_job.go", "create_namespace.go",

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Why is this needed: Because of is not recommended to create cronjob (with flags) anymore. But there is no imperative command available for to create cronjob. /sig CLI <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
GitHub didn't allow me to assign the following users: Pingan2017. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i wanna work on this. give me several days
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
Code change:
func mustBeHealthy(t kubeapiservertesting.Logger, checkName, wantBodyContains string, clientConfig *rest.Config, excludes ...string) { t.Helper() var restErr error <del> pollErr := wait.PollImmediate(2*time.Second, 2*time.Minute, func() (bool, error) { </del> <ins> pollErr := wait.PollImmediate(1*time.Second, 5*time.Minute, func() (bool, error) { </ins> body, ok, err := getHealthz(checkName, clientConfig, excludes...) restErr = err if err != nil {

Related discussion:
text: {Failed === RUN TestKMSv2Healthz --- FAIL: TestKMSv2Healthz (167.38s) also shown in " TestKMSv2Healthz": 1, Not sure No response No response /sig auth
/assign /triage accepted Use for poll interval Change the poll timeout to 5m Update the poll error check (check if not nil)
Code change:
const unversionedWarningPre = ` <!-- BEGIN STRIP_FOR_RELEASE --> <del> <img src="http://kubernetes.io/img/warning.png" alt="WARNING" </del> <ins> <img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" </ins> width="25" height="25"> <del> <img src="http://kubernetes.io/img/warning.png" alt="WARNING" </del> <ins> <img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" </ins> width="25" height="25"> <del> <img src="http://kubernetes.io/img/warning.png" alt="WARNING" </del> <ins> <img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" </ins> width="25" height="25"> <del> <img src="http://kubernetes.io/img/warning.png" alt="WARNING" </del> <ins> <img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" </ins> width="25" height="25"> <del> <img src="http://kubernetes.io/img/warning.png" alt="WARNING" </del> <ins> <img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING" </ins> width="25" height="25"> <h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2>

Related discussion:
text: This includes but effects multiple docs.
This issue was also raised on the repository, see:
What's needed to fix this? Are the broken headers being generated automatically somewhere?
- The warning section is pre-pended to the md docs from the following script The fixes this issue, updating this script and all the docs... However, there is an open question as to whether "old" docs should be removed from this repo, which has prevented this PR from being merged.
Code change:
return portsToEndpoints } <ins> // ContainsIPv4Loopback returns true if the input is empty or one of the CIDR contains an IPv4 loopback address. func ContainsIPv4Loopback(cidrStrings []string) bool { if len(cidrStrings) == 0 { return true } // RFC 5735 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address ipv4LoopbackStart := netutils.ParseIPSloppy("127.0.0.0") for _, cidr := range cidrStrings { if IsZeroCIDR(cidr) { return true } ip, ipnet, err := netutils.ParseCIDRSloppy(cidr) if err != nil { continue } if netutils.IsIPv6CIDR(ipnet) { continue } if ip.IsLoopback() { return true } if ipnet.Contains(ipv4LoopbackStart) { return true } } return false } </ins> // IsZeroCIDR checks whether the input CIDR string is either // the IPv4 or IPv6 zero CIDR func IsZeroCIDR(cidr string) bool {

Related discussion:
text: Just similar to , for service with type nodeport , iptable proxy should add IsLoopback check for nodeAddress. Line 1104-1106 check nodeAddress is localhost address or not for ipvs mode proxy but for iptable mode proxy , when deal with nodePort type service, there is no similar check for nodeAddress since the use of localhost addresses for nodeports is the only know reason to require (), Just for the purpose of security ,this requirement shall be removed for proxy-mode=itable. Start a cluster with proxy-mode=iptable and some services Do; iptable -Ln | grep 127.0.0.1 just as says : ipv6+iptables , ::1 is not work for Nodeport all supporting proxy-mode=iptable any any /sig network /kind cleanup /area iptable
/sig network
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area iptable 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
/kind cleanup
maybe I'm missing something, but this was discussed in this issue and iptables needs to use localhost for nodeports, if we remove that we can break users. ipvs is different and it never needed loopback for nodeports
set sysctlRouteLocalnet when running in IPtable mode may still face a risk from CVE-2020-8558, so why not disable it in the future version?
because there are users that depend on that behavior, I can't remember the details , the referenced issue has them
I support finding a way to get to the end-state of not supporting nodeports on localhost, but I don't know the path.
/assign
it seems that localhost;nodeport is also used in blogs and forums the only tool we have for these situations is to add a feature gate and rollout the change in several releases, users can always set the sysctl value by themselves to recover previous behavior. should I create a small KEP to deprecate the behavior of setting the TTL? since is inconsistent with the other kube-proxy modes, there is a security risk and the workaround is quite simple, it seems a reasonable decision
I don't think we have a clear path to changing a defsult behavior, even one that is ill-advised.
Code change:
return portsToEndpoints } <ins> // ContainsIPv4Loopback returns true if the input is empty or one of the CIDR contains an IPv4 loopback address. func ContainsIPv4Loopback(cidrStrings []string) bool { if len(cidrStrings) == 0 { return true } // RFC 5735 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address ipv4LoopbackStart := netutils.ParseIPSloppy("127.0.0.0") for _, cidr := range cidrStrings { if IsZeroCIDR(cidr) { return true } ip, ipnet, err := netutils.ParseCIDRSloppy(cidr) if err != nil { continue } if netutils.IsIPv6CIDR(ipnet) { continue } if ip.IsLoopback() { return true } if ipnet.Contains(ipv4LoopbackStart) { return true } } return false } </ins> // IsZeroCIDR checks whether the input CIDR string is either // the IPv4 or IPv6 zero CIDR func IsZeroCIDR(cidr string) bool {

Related discussion:
text: As much as I'd like it to be the default, I think the only way to get there is to add a flag with compatible default behavior and encourage people to turn it on. e.g. add a kube-proxy config like defaulting to true, and encourage people/tools to set it to false.
I've found a better way ;)
/triage accepted
Code change:
return r, pods, svc } <ins> func JSONToYAMLOrDie(in []byte) []byte { data, err := yaml.JSONToYAML(in) if err != nil { panic(err) } return data } func streamYAMLTestData() (io.Reader, *api.PodList, *api.ServiceList) { pods, svc := testData() r, w := io.Pipe() go func() { defer w.Close() w.Write(JSONToYAMLOrDie([]byte(runtime.EncodeOrDie(latest.Codec, pods)))) w.Write([]byte("n---n")) w.Write(JSONToYAMLOrDie([]byte(runtime.EncodeOrDie(latest.Codec, svc)))) }() return r, pods, svc } </ins> type testVisitor struct { InjectErr error Infos     []*Info

Related discussion:
text: If I stuff into a file and use that after -f, it works fine. cc
What's on stdin?
Bug, I'm only accepting json because I naively reused watch partitioner and we don't have test cases. Will fix tonight.
If that's the problem, why did it work when I gave it that file not over stdin?
Different code path. Stdin supports streaming json a la watch (multiple json objects in a stream), so you can do Unfortunately I missed yaml input and didn't use a segmenting yaml decoder (returning a stream of yaml objects).
Ah! Thanks for explanation. I think it would be good for us to ask for e2e runs before merging kubectl changes, since there's not quite enough coverage in test- yet.
Yeah, I'm slacking on that for these changes.
Fix incoming.
Fix provided. More tests to test-cmd... :)
Code change:
return defaultPlugins } <ins> type pluginIndex struct { index  int plugin v1beta2.Plugin } </ins> func mergePluginSet(defaultPluginSet, customPluginSet v1beta2.PluginSet) v1beta2.PluginSet { disabledPlugins := sets.NewString() <ins> enabledCustomPlugins := make(map[string]pluginIndex) </ins> for _, disabledPlugin := range customPluginSet.Disabled { disabledPlugins.Insert(disabledPlugin.Name) } <ins> for index, enabledPlugin := range customPluginSet.Enabled { enabledCustomPlugins[enabledPlugin.Name] = pluginIndex{index, enabledPlugin} } </ins> var enabledPlugins []v1beta2.Plugin if !disabledPlugins.Has("*") { for _, defaultEnabledPlugin := range defaultPluginSet.Enabled { if disabledPlugins.Has(defaultEnabledPlugin.Name) { continue } <ins> // The default plugin is explicitly re-configured, update the default plugin accordingly. if customPlugin, ok := enabledCustomPlugins[defaultEnabledPlugin.Name]; ok { klog.InfoS("Defaut plugin is explicitly re-configured and is overriding.", "plugin", defaultEnabledPlugin.Name) // update the default plugin in place to preserve order defaultEnabledPlugin = customPlugin.plugin // kick the plugin from the enabled list of custom plugins customPluginSet.Enabled = append(customPluginSet.Enabled[:customPlugin.index], customPluginSet.Enabled[customPlugin.index+1:]...) } </ins> enabledPlugins = append(enabledPlugins, defaultEnabledPlugin) } }

Related discussion:
text: No, just "enabled" would NOT move things to the end of the list (it will preserve order), but "disabled and enabled" would move to the end of the list.
ok, that sounds good
Another problem here is if we don't want to overridden anything but just config a plugin which is accidently a default plugin, something like below, scheduler will fail as well, I think we need to De-dup here instead of just a warning here. I guess this PR should already cover this, I will go back to check it again, at least one more testcase is needed to cover this case. keep current logic to warn users that "PluginXYZ" is already registered (by default), if it's a non-Score plugin
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-contributor-experience at . /lifecycle stale
/lifecycle stale let me revive the PR later.
/remove-lifecycle stale
Code change:
podClient = f.PodClient() }) <del> It("should invoke init containers on a RestartNever pod", func() { </del> <ins> /* Release: v1.12 Testname: init-container-starts-app-restartnever-pod Description: Ensure that all InitContainers are started and all containers in pod are voluntarily terminated with exit status 0, and the system is not going to restart any of these containers when Pod has restart policy as RestartNever. */ framework.ConformanceIt("should invoke init containers on a RestartNever pod", func() { </ins> By("creating the pod") name := "pod-init-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Evaluating e2e tests based on available options which are covering important aspects with user scenarios and eligible to promote for conformance. What you expected to happen: These 4 e2e tests evaluate different and based on . [NodeConformance] should invoke init containers on a RestartNever pod [NodeConformance] should invoke init containers on a RestartAlways pod [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod Anything else we need to know?: comment, Are these tests good to promote for conformance or do we need to look on other aspects as well ? are observed api endpoint hits during tests execution. (API coverage improvement) - InitContainer [NodeConformance] should invoke init containers on a RestartNever pod InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod InitContainer [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod InitContainer [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod /area conformance cc
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Go ahead and open a PR to ask this question. Yes == PR is merged, no == PR is closed (or amended to doc the reason these tests can't be promoted)
Code change:
m.updateAllocatedDevices(m.activePods()) allocatedDevicesUpdated = true } <del> allocDevices, err := m.devicesToAllocate(podUID, contName, resource, needed) </del> <ins> allocDevices, err := m.devicesToAllocate(podUID, contName, resource, needed, devicesToReuse[resource]) </ins> if err != nil { return err }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area hw-accelerators What happened: In the context of the device plugin, when using init containers in your pod spec, the current behavior will not reuse devices between init containers and regular containers. This is problematic as Pod scheduling is currently wrong: , the current predicate algorithm rightly assumes the maximum number of devices in use at one time is . However, the pod predicate ran on the node is the sum of devices used by regular and init containers. Meaning that your pod can bounce back between the scheduler and a node infinitely. Also given that many of the extended resources are typically more expensive that the built-in ones like CPU, Memory and Storage this bug has very real financial drawbacks in terms of resource usage (e.g: using 4 GPUs on a pod that only uses 2 GPUs at a time). Furthermore, this unexpected behavior was caught during implementation (but we did not catch the scheduling implications) and decision was taken to ignore it for the first implementation. We need to document it for 1.9 What you expected to happen: Devices can be reused by Init Containers Correct resource accounting In terms of the current behavior of the Allocate call to the device plugin, I'd expect the allocate call to be done before every Init containers start and once at the end of the last Init container (for regular containers). /assign
Yep, I realized the inconsistency between the predicate behavior of scheduler and that of node too. Having said that, considering we treat a pod as a whole when predicating currently, it's kind of difficult to reuse the runtime informations between init containers and regular containers. The real crux of the matter might be whether the scenario of requiring extended resources in init containers is common, if so, the issue should be addressed ASAP.
If I remembered correctly, the current design to improve DP includes a reconciliation in admit phase of Pod, it may be able to fix Allocate call for
can you point me to said design ? I'm not sure that the Allocate call for init containers is planned to be fixed as described.
Can you guys please point to the code where is happening. Looks to me that same logic is executed on both the scheduler and the node to calculate a pod's resource request and which is  On the node, function call tree looks like this: Is it possible to add few more words in explanation?