jiebi/CodeConvo huggingface dataset:
Change:
if o.Resource != (schema.GroupVersionResource{}) || o.ResourceName != "" { return fmt.Errorf("NonResourceURL and ResourceName can not specified together") } <ins> } else if !o.Resource.Empty() && !o.AllNamespaces && o.DiscoveryClient != nil { if namespaced, err := isNamespaced(o.Resource, o.DiscoveryClient); err == nil && !namespaced { if len(o.Resource.Group) == 0 { fmt.Fprintf(o.ErrOut, "Warning: resource '%s' is not namespace scopedn", o.Resource.Resource) } else { fmt.Fprintf(o.ErrOut, "Warning: resource '%s' is not namespace scoped in group '%s'n", o.Resource.Resource, o.Resource.Group) } } </ins> } if o.NoHeaders {

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 you expected to happen: if returns true I expect to be able to perform the action without issue. Note in this case my service user has a rolebinding in a single namespace (and that is also what my kubecontext is set to.) if I change my default to a different namespace then the command returns false How to reproduce it (as minimally and precisely as possible): create a namespace (test) create a service account in that namespace create a role that gives get list and watch permissions to create a rolebinding from that role to the service account. Anything else we need to know?: this is special because namespaces are not scoped to a namespace. if you replace the command with then you get the exepcted result however this breaks the path of least suprise. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig auth
asks the authorization system if the given verb can be performed on the given noun at the given scope. It does not interpret whether the resource exists at that scope. We could warn if we find the specified resource and it does not exist at the specified scope (just like we warn if you ask about a resource that we can't find), but we would still interrogate the authorization system and return the results as we do today. /kind feature /remove-kind bug
/cc
Change:
nodePortAddressStrings []string, kernelHandler KernelHandler, ) (*Proxier, error) { <del> // Proxy needs br_netfilter and bridge-nf-call-iptables=1 when containers // are connected to a Linux bridge (but not SDN bridges).  Until most // plugins handle this, log when config is missing if val, err := sysctl.GetSysctl(sysctlBridgeCallIPTables); err == nil && val != 1 { klog.InfoS("Missing br-netfilter module or unset sysctl br-nf-call-iptables, proxy may not work as intended") } </del> // Set the conntrack sysctl we need for if err := proxyutil.EnsureSysctl(sysctl, sysctlVSConnTrack, 1); err != nil { return nil, err

Discussion:
The check in: is incorrect. It misses the case when the sysctl doesn't exist (err != nil). /sig network /area ipvs /area kube-proxy The check sould be: To reproduce you must use a kernel without the function, or the module unloaded. This is likely not easy if a regular Linux distro is used. But IMO no e2e testing should be needed (none exist now). It's just a warning that may be missed, so nothing urgent. master (all) N/A N/A N/A N/A N/A
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
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
removed one of those , it looks that we should remove this to be consistent
I can work on removing the code to maintain consistency. Can you please assign this issue to me
/assign You can also use to assign the issue to yourself.
oops, I should have thought to check ipvs backend too
Change:
// On gci, root is read-only and controller-manager containerized. Assume // controller-manager has started with --flex-volume-plugin-dir equal to this // (see cluster/gce/config-test.sh) <del> gciVolumePluginDir        = "/home/kubernetes/flexvolume" gciVolumePluginDirLegacy  = "/etc/srv/kubernetes/kubelet-plugins/volume/exec" gciVolumePluginDirVersion = "1.10.0" detachTimeout             = 10 * time.Second </del> <ins> gciVolumePluginDir = "/home/kubernetes/flexvolume" detachTimeout      = 10 * time.Second </ins> ) // testFlexVolume tests that a client pod using a given flexvolume driver

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: I think these jobs do not have the flexvolume directory properly configured. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
Change:
<del> /* Copyright 2016 The Kubernetes Authors. 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. */ package filters import ( "net/http" "runtime/debug" "github.com/golang/glog" apierrors "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/util/runtime" apirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/server/httplog" ) // WithPanicRecovery wraps an http Handler to recover and log panics. func WithPanicRecovery(handler http.Handler, requestContextMapper apirequest.RequestContextMapper) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) { defer runtime.HandleCrash(func(err interface{}) { http.Error(w, "This request caused apisever to panic. Look in log for details.", http.StatusInternalServerError) glog.Errorf("APIServer panic'd on %v %v: %vn%sn", req.Method, req.RequestURI, err, debug.Stack()) }) logger := httplog.NewLogged(req, &w) var requestInfo *apirequest.RequestInfo ctx, ok := requestContextMapper.Get(req) if !ok { glog.Errorf("no context found for request, handler chain must be wrong") } else { requestInfo, ok = apirequest.RequestInfoFrom(ctx) if !ok { glog.Errorf("no RequestInfo found in context, handler chain must be wrong") } } if !ok || requestInfo.Verb != "proxy" { logger.StacktraceWhen( httplog.StatusIsNot( http.StatusOK, http.StatusCreated, http.StatusAccepted, http.StatusBadRequest, http.StatusMovedPermanently, http.StatusTemporaryRedirect, http.StatusConflict, http.StatusNotFound, http.StatusUnauthorized, http.StatusForbidden, http.StatusNotModified, apierrors.StatusUnprocessableEntity, http.StatusSwitchingProtocols, ), ) } defer logger.Log() // Dispatch to the internal handler handler.ServeHTTP(w, req) }) } </del>

Discussion:
This is simple cleanup. It is unnecessarily disconcerting to read through apiserver logs and find every log line is from the file "". We should adjust the code printing these lines, either by changing the file name, or (ideally) by making it more intelligent about logging the source of the call (e.g., callers--).
, i'd like to try this one :).
No activity on this one, will try to fix it.
Has it been resolved? Can I try?
check out for discussion about it.
Change:
} // Keep trying to create an invalid instance of the CRD until we <del> // get an error containing the ResourceVersion we are looking for </del> <ins> // get an error containing the message we are looking for </ins> // counter := 0 return wait.PollUntilContextCancel(context.TODO(), 100*time.Millisecond, true, func(_ context.Context) (done bool, err error) {

Discussion:
integration TestRatchetingFunctionality/Enum TestRatchetingFunctionality/MinPropertiesMaxProperties TestRatchetingFunctionality/CELOptionalOldSelf TestRatchetingFunctionality/ TestRatchetingFunctionality/ since 3/8 No response /sig api-machinery
/assign /triage accepted
Change:
- [Urgent Upgrade Notes](#urgent-upgrade-notes) - [(No, really, you MUST read this before you upgrade)](#no-really-you-must-read-this-before-you-upgrade) - [Known Issues](#known-issues) <del> - [Etcd v3.5.[0-2] data corruption](#etcd-v350-2-data-corruption) </del> <ins> - [Etcd v3.5.[0-2] data corruption](#etcd-v350-2-data-corruption) </ins> - [Changes by Kind](#changes-by-kind-14) - [Deprecation](#deprecation) - [API Change](#api-change-5)

Discussion:
The section of the Changelog for 1.23.14 (and sibling bugfix releases) says that 1.23.13 both has the vuln and also has the fix. The Fix version should be 1.23.14 in the above and sibling changelogs. Load the link above. No response N/A N/A N/A N/A N/A N/A
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 docs
cc
For v1.23.14, the title is . This seems to be valid. means
You're looking at the wrong text. Follow the link and see .13 in both lists: kube-apiserver v1.25.0 - v1.25.3 kube-apiserver v1.24.0 - v1.24.7 kube-apiserver v1.23.0 - v1.23.13 kube-apiserver v1.22.0 - v1.22.15 kube-apiserver <= v1.21.? kube-apiserver v1.25.4 kube-apiserver v1.24.8 kube-apiserver v1.23.13 kube-apiserver v1.22.16
Got it. Thanks for pointing out the location.
I opened to fix it.
/reopen Can you please cherry-pick to the release branches (1.25-1.22)?
Reopened this issue. <detailsIn response to : /reopen Can you please cherry-pick to the release branches (1.25-1.22)? 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
Of course. Done
Cherry-picks are done, thanks a lot /close
Closing this issue. <detailsIn response to : Cherry-picks are done, thanks a lot /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:
} r := &Reflector{ <del> name:                   "test-reflector", listerWatcher:          lw, store:                  NewFIFO(MetaNamespaceKeyFunc), initConnBackoffManager: bm, clock:                  fakeClock, watchErrorHandler:      WatchErrorHandler(DefaultWatchErrorHandler), </del> <ins> name:              "test-reflector", listerWatcher:     lw, store:             NewFIFO(MetaNamespaceKeyFunc), backoffManager:    bm, clock:             fakeClock, watchErrorHandler: WatchErrorHandler(DefaultWatchErrorHandler), </ins> } r.MaxInternalErrorRetryDuration = tc.maxInternalDuration

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
local wait=${3:-1} local times=${4:-30} local maxtime=${5:-1} <del> local extra_args=${6:-} </del> command -v curl >/dev/null || { kube::log::usage "curl must be installed"

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? Environment: Kubernetes version (use ):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 api-machinery
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
COPY --from=servercore-helper /Windows/System32/netapi32.dll /Windows/System32/netapi32.dll COPY --from=prep /coredns.exe /coredns.exe COPY --from=prep /iperf /iperf <ins> COPY --from=prep /wincoreutils/sync.exe /bin/sync.exe </ins> # NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, which is not desirable. ENV PATH="C:dig;C:bin;C:curl;C:Windowssystem32;C:Windows;C:Program FilesPowerShell;"

Discussion:
We'd like to add to the windows nodes Discussed in , some storage e2e tests need the call to flush data to disk, this utility is not available in windows nodes or agnhost /sig storage /sig testing
/sig testing
/sig storage /kind flake
/sig windows
Does sync only need to be in Agnhost or also on the Windows node? I don't think there is any issue with adding to the agnhost for this tests. Has it been tested that it works? /cc in case you have thoughts
In the README of sync it says: Initially I thought it could be to agnhost however told me that Windows containers cannot run in privileged mode as of today. cc
Since we run the Windows Test containers as they should have full access to modify the host files if the host path is mapped in.
I downloaded the zip file and I checked that it has an EULA, do you know which sig would help with the license?
Hm, if the sysinternal is problematic, what about the GNU one? It seems to come from coreutils, which can easily be downloaded and extracted from. Hopefully, they are 64-bit binaries. Anyways, I think adding is a good idea, there are a few other non-conformance tests that are calling sync.
I believe that would be sig-contributor-experience. I thought we were using other sys-internal tools as well but it is a good idea to double check.
/triage accepted /assign
/remove-sig testing we don't own the nodes (?)
I've sent , which would add using that PR. Let us know if that satisfies your requirements, we could merge afterwards.
Thanks I guess we can merge the PR and I can run the storage e2e tests that need .
Change:
// When feature-gate for TaintBasedEvictions=true flag is enabled, // TaintNodeNotReady would be automatically added by node controller // when node is not ready, and removed when node becomes ready. <del> TaintNodeNotReady = "node.alpha.kubernetes.io/notReady" </del> <ins> TaintNodeNotReady = "node.kubernetes.io/not-ready" // DeprecatedTaintNodeNotReady is the deprecated version of TaintNodeNotReady. // It is deprecated since 1.9 DeprecatedTaintNodeNotReady = "node.alpha.kubernetes.io/notReady" </ins> // When feature-gate for TaintBasedEvictions=true flag is enabled, // TaintNodeUnreachable would be automatically added by node controller

Discussion:
Almost all style strings use dashes, rather than javascript names. vs .
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Thanks for notification, a quick fix is submitted.
/cc
The PR here isn't merged yet. Can we make that happen please? We're still in alpha, so should be ok
Should I add the v1.8 milestone to this issue?
Hope so. We are pending in , need approve from
I opened with safe changes. "not-ready" change needs to be discussed more, as it's a breaking change. I believe it's best with fixing that to the time we'll be moving to beta, as we'll need to do another breaking change, i.e. remove 'alpha' from the key.
Aren't we doing this at the 11th hour? Is this going to hit 1.8?
Strings like this that are part of the core API should be part of a design doc that is formally reviewed by an API group. We need to find ways to catch this stuff earlier. We should also have an evolving API style guide that lists stuff like this. /cc
Thanks , let me make some summary: quick fix for 1.8 is , will be merged soon. final fix is , we are collaborating to reach a final solution and it's not target 1.8
Agree with Joe, can someone open a PR to that documents that taint names should follow the naming conventions for annotations?
Change:
return true, binding, nil }) controllers := make(map[string]string) <del> stopFn := broadcaster.StartEventWatcher(func(obj runtime.Object) { </del> <ins> stopFn, err := broadcaster.StartEventWatcher(func(obj runtime.Object) { </ins> e, ok := obj.(*eventsv1.Event) if !ok || e.Reason != "Scheduled" { return

Discussion:
Follow-up cleanup work for: Most of the information about this issue can be found in , where the work merged with a to change the function signature of to return a func() as well as an error. This issue will help to track that. All TODOs introduced in are resolved. N/A N/A <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority low 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
/cc /triage accepted
/priority important-longterm
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
"//vendor/github.com/coreos/etcd/client:go_default_library", "//vendor/github.com/coreos/etcd/clientv3:go_default_library", "//vendor/github.com/coreos/etcd/pkg/transport:go_default_library", <ins> "//vendor/github.com/grpc-ecosystem/go-grpc-prometheus:go_default_library", "//vendor/google.golang.org/grpc:go_default_library", </ins> ], )

Discussion:
/kind feature Can we provide a way to enable etcd clientv3 prometheus metrics at the apiserver side ? The etcd.clientv3 interface is instantiated and it does not enable metrics. In file in coreos/etcd, one can see the to pass to enable metrics. It would be great if the apiserver has a command line parameter, config/environment variable to enable etcd.clientv3 metrics.
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
This issue is quite similar to
Yes, this is a good idea, in fact we just released a new version of the package required for this.
/assign
I can do it.
oh, maybe I should use the new features to implement, I will continue to modify it.
are you referring to injecting the registry to use? Yes I would very much appreciate that, even if we (for now) inject the , that will allow us to modify that more easily in the future.