jiebi/CodeConvo huggingface dataset:
Change:
var responseTimes, creationTimes []time.Duration var ingController *IngressController <del> f := framework.Framework{BaseName: "glbc"} </del> <ins> f := framework.NewDefaultFramework("glbc") </ins> BeforeEach(func() { // This test requires a GCE/GKE only cluster-addon

Discussion:
Sometime yesterday the test started panicking because the framework is nil. No changes were made to the test, did we change framework setup? This is the stack
Aarg now it looks like we inverted the order of running framework.AfterEach and custom AfterEach, so I re-invoke framework.AfterEach in my AfterEach (we used to need this) and it crashes. I'm just going to usher in as it doesn't invoke framework.AfterEach. For the record this will keep failing on 1.3 till the is cherrypicked, but the diff between 1.3 and HEAD is insignificant at this point (and remain insignificant till the cherrypick happens)
Now gce-1.3 passes but will fail because went in without They should pass when is cherrypicked to 1.3 ( for context)
Change:
} dest.Paths.Paths[k] = v } <ins> return nil </ins> }

Discussion:
Related to Seeing the following errors in kube-apiserver logs when CRDs are applied: No errors in logs Apply any CRD manifest No response <details</details<details</details<details</details<detailsRancher RKE2 </details<detailscontainerd 1.6.4 </details<detailscanal </details
/sig api-machinery
/assign
Did this cause any specific trouble to your cluster I'm curious what the impact/severity of this is.
Everything seems to work fine, but there's a bunch of log spew every time a CRD manifest is loaded. In K3s we mix all the control-plane component logs together in a single pair of stdout/stderr streams so it's quite noisy, compared to previous releases. The fact that these come out at WARN level with a scary prefix makes them look pretty serious, and I expect we will get a fair bit of users asking about it once we release.
/triage accepted
Change:
go_rules_dependencies() go_register_toolchains( <del> go_version = "1.11.2", </del> <ins> go_version = "1.11.3", </ins> ) docker_repositories()

Discussion:
The go team has released 1.11.3 with three security fixes. From their e-mail announcement: We should kick off upgrades of both the kubernetes build system, and our CI, as soon as possible. Do you have an ETA for the rules_go bump that will contain 1.11.3 toolchain support? cc:
I'm preparing releases that use Go 1.11.3 by default. Those will be on the rules_go 0.14, 0.15, and 0.16 branches. I expect to tag them tonight as soon as they get through CI.
Fantastic! Thank you
rules_go 0.14.7, 0.15.9, and 0.16.4 are now tagged and ready to go.
related commits and issue:
Reopening to track other branches, as well as the CI bump
go1.11.3 and go1.10.6 introduced a regression, and so go1.11.4 and go1.10.7 were released Friday afternoon with a fix. We'll need to bump everything again on master, and should hold off on cherry-picks for now.
This looks fixed by Is there anything else that needs to be done as well?
Still need to merge for k8s 1.13.
Closing as all branches are now up to date.
Change:
readonly UUID_MNT_PREFIX="/mnt/disks/by-uuid/google-local-ssds" readonly UUID_BLOCK_PREFIX="/dev/disk/by-uuid/google-local-ssds" <ins> readonly COREDNS_AUTOSCALER="Deployment/coredns" readonly KUBEDNS_AUTOSCALER="Deployment/kube-dns" </ins> # Use --retry-connrefused opt only if it's supported by curl. CURL_RETRY_CONNREFUSED=""

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:
} func validateProxyMode(mode kubeproxyconfig.ProxyMode, fldPath *field.Path) field.ErrorList { <ins> if runtime.GOOS == "windows" { return validateProxyModeWindows(mode, fldPath) } return validateProxyModeLinux(mode, fldPath) } func validateProxyModeLinux(mode kubeproxyconfig.ProxyMode, fldPath *field.Path) field.ErrorList { </ins> allErrs := field.ErrorList{} switch mode { case kubeproxyconfig.ProxyModeUserspace: case kubeproxyconfig.ProxyModeIPTables:

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <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
Change:
return client.TokenReviews(), nil } <ins> type ignorableError struct{ error } </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When I start the core API server with , it populates the ConfigMap in namespace with the requestheader CA. This allows the extension API server to dynamically discover the CA and use it for validating the client certificate of aggregator layer. See for documentation However, if the core API server doesn't use certificate based authentication for it's clients i.e. flag isn't set in core API server then the extension API server fails to start with error message I believe this is coming from bootstrap code in extension API server . What you expected to happen: Extension API server should be able to start and not require that both and be present in the ConfigMap. This allows Kubernetes clusters which don't use certificate based authentication for core API server to be able to dynamically discover the requestheader-ca instead of having to mount it as a secret. How to reproduce it (as minimally and precisely as possible): Create a Kubernetes cluster which uses non certificate based authentication for core API server like Webhook based authentication. Example: You can launch an Amazon EKS cluster which uses Webhook based authentication following steps outlined . Setup aggregator layer by adding flags mentioned . CA certificate and client certificate for aggregator layer can be generated using and . Deploy metrics server to cluster following steps in Deployment section of README Get logs of metrics server pod and it should be failing with error message above Anything else we need to know?: It's possible there is a reason which is not evident to me as to why extension API server would require both client-ca-file and requestheader-client-ca-file to be present in the ConfigMap. Environment: Kubernetes version (use ): 1.10.3 Cloud provider or hardware configuration: Amazon EKS OS (e.g. from /etc/os-release): Kubernetes control plane and nodes = Amazon Linux 2 (2017.12) LTS Release Candidate (4.14.42).
/sig api-machinery /cc
since it looks like the at-mention didn't take
/sig auth /assign
Thanks Jordan. This is something we are interested in contributing to and ask for being cherrypicked to patch releases of 1.10.x and 1.11.x. That conversation can wait once we have the PR out.

Quick update: I'm working on sending a PR for this issue by this week
- Now that this is merged, can we open up the possibility of cherry picking to 1.10.x and 1.11.X please?
sure, opened , ,
Change:
// CommonAccessor returns a Common interface for the provided object or an error if the object does // not provide List. <del> // TODO: return bool instead of error </del> func CommonAccessor(obj interface{}) (metav1.Common, error) { switch t := obj.(type) { case List:

Discussion:
Anything else we need to know?: I notice there are TODOs in apimachinerypkgapimeta,return bool instead of error func CommonAccessor, ListAccessor, Accessor. If is it necessary to do,I push a PR for it. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
cc
/sig api-machinery
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
for shortName, imageConfig := range externalImageConfig.Images { var images []string isRegex, name := false, shortName <del> if imageConfig.ImageRegex != "" && imageConfig.Image == "" { </del> <ins> if (imageConfig.ImageRegex != "" || imageConfig.ImageFamily != "") && imageConfig.Image == "" { </ins> isRegex = true <del> images, err = getGCEImages(imageConfig.ImageRegex, imageConfig.Project, imageConfig.PreviousImages) </del> <ins> images, err = getGCEImages(imageConfig.ImageRegex, imageConfig.ImageFamily, imageConfig.Project, imageConfig.PreviousImages) </ins> if err != nil { <del> klog.Fatalf("Could not retrieve list of images based on image prefix %q: %v", imageConfig.ImageRegex, err) </del> <ins> klog.Fatalf("Could not retrieve list of images based on image prefix %q and family %q: %v", imageConfig.ImageRegex, imageConfig.ImageFamily, err) </ins> } } else { images = []string{imageConfig.Image}

Discussion:
We should support image family in node e2e image config. It makes image validation much easier on GCE.
Cool idea :) Adding a link to for anyone like me who hadn't heard of them before :)
Change:
"crypto/x509" "fmt" "io/ioutil" <ins> "strings" </ins> "github.com/Azure/go-autorest/autorest/adal" "github.com/Azure/go-autorest/autorest/azure"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need to enhance Azure cloud provider code to support both AAD and ADFS authentication. Why is this needed: On Azure Stack customer can have two type of deployment .
/sig azure
/assign
Change:
k8s.io/mount-utils v0.0.0 k8s.io/pod-security-admission v0.0.0 k8s.io/sample-apiserver v0.0.0 <del> k8s.io/system-validators v1.5.0 </del> <ins> k8s.io/system-validators v1.6.0 </ins> k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b sigs.k8s.io/structured-merge-diff/v4 v4.2.0 sigs.k8s.io/yaml v1.2.0

Discussion:
every k8s release, if changes are to we release a new version of the library and vendor it in this repository. TODO: [ ] wait for changes to accumulate in [ ] add new release in before the k8s 1.23 release [ ] vendor the new release in k/k (example PR: )
/sig cluster-lifecycle node /milestone v1.23 /assign
/triage accepted
/cc
Change:
var ( // TODO: Deprecate gitMajor and gitMinor, use only gitVersion instead. gitMajor     string = "0"              // major version, always numeric <del> gitMinor     string = "8.2+"           // minor version, numeric possibly followed by "+" gitVersion   string = "v0.8.2-dev"     // version from git, output of $(git describe) </del> <ins> gitMinor     string = "8.3"            // minor version, numeric possibly followed by "+" gitVersion   string = "v0.8.3"         // version from git, output of $(git describe) </ins> gitCommit    string = ""               // sha1 from git, output of $(git rev-parse HEAD) gitTreeState string = "not a git tree" // state of git tree, either "clean" or "dirty" )

Discussion:
The web and instructions for [Installing and Setting Up kubectl] need a slight tuneup. The homebrew instructions should reflect a few different options for Bash on macOS. bash-completion is for Bash 3.2 (macOS default), and bash-completion is for Bash 4.1+ (upgraded GNU Bash) I lost an hour of my life to this; I hope this helps others. What happened: By following the homebrew install instructions on this page, then entering and tabbing, this is the output: What you expected to happen: By following the same path as above this should be the output: Anything else we need to know: Currently the instructions assume the default Bash on a vanilla macOS install; while I understand this being most-likely scenario, the default version of Bash is shamefully old. After reviewing to options in homebrew it appears there are 2: -completion is for Bash 3.2 and -completion is for Bash 4.1+ For those of us that cannot live without all the options, this is how we do: Install: Configure Then the needs to be updated to reflect this changes: TEST a new tab (the is sourced-in) and tab twice We then get the expected result. The requested details follow: Kubernetes version (use ): Environment: personal/dev Cloud provider or hardware configuration: NA OS (e.g. from /etc/os-release): macOS Sierra Kernel (e.g. ): Install tools: homebrew [Installing and Setting Up kubectl]
So were you running bash 3.2 or bash 4 prior to this? It looks like the instructions are for bash-completion which should be for the bash installed by default in macOS. /assign
I always install the latest Bash, currently 4.4.12(1)-release. Apple's is too old and I'm not going live in their cave; most people won't - that's why homebrew is a huge project. Correct, the instructions are for the stock version of Bash (presently 3.2.57(1)-release). My suggestion is to include instructions for both versions. Mostly to keep others from wasting the same time. I've already done the testing so folding in the new details should be pretty straight-forward.
I've opened to update the kubernetes documentation, and to potentially update how homebrew works to make this clearer.
Docs have been updated: /close
Change:
<del> load("@io_bazel_rules_go//go:def.bzl", "go_library") </del> <ins> package(default_visibility = ["//visibility:public"]) load( "@io_bazel_rules_go//go:def.bzl", "go_library", "go_test", ) </ins> go_library( name = "go_default_library",

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: There are no unit tests yet for pkg , we should add unit tests. What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
Change:
} } <ins> // Drop the packets in INVALID state, which would potentially cause // unexpected connection reset. // https://github.com/kubernetes/kubernetes/issues/74839 writeLine(proxier.filterRules, "-A", string(kubeForwardChain), "-m", "conntrack", "--ctstate", "INVALID", "-j", "DROP", ) </ins> // If the masqueradeMark has been added then we want to forward that same // traffic, this allows NodePort traffic to be forwarded even if the default // FORWARD policy is not accept.

Discussion:
What happened: Network services with heavy load will cause "connection reset" from time to time. Especially those with big payloads. When packets with sequence number out-of-window arrived k8s node, conntrack marked them as INVALID. kube-proxy will ignore them, without rewriting DNAT. The packet goes back the the original pod, who doesn't recognize the packet because of the wrong source ip, end up RSTing the connection. What you expected to happen: connection not reset How to reproduce it (as minimally and precisely as possible): wrote this just to reproduce the issue: Basically run it in a cluster, and after a while you will be able to see "Connection reset by peer" on both server and client pods. Anything else we need to know?: Related issue: Environment: Kubernetes version (use ): 1.11.7 Cloud provider or hardware configuration: gke (should be general to all provider) OS (e.g: ): PRETTYNAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSIONID="9" VERSION="9 (stretch)" ID=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" Kernel (e.g. ): Linux gke-cluster-1-11-default-pool--6nzv 4.14.89+ SMP Wed Jan 9 13:35:00 PST 2019 x86_64 GNU/Linux
/sig network
I created a small app to reproduce this issue:
I've been hitting this exact problem for packets between a Pod and the outside world. So the DROP rule has to go into the INPUT chain. Would that be a job for a CNI driver or the kube-proxy?
was put to iptables mode but not to , right? Isn't ipvs mode affected by this issue, too?
Can anyone point me out how netfilter ignore this STATE invalid packet? I checked the code in netfilter for function iptablenatdo_chain, but didn't find the code that handles the STATE=invalid packet. Thanks for help.
Invalid is connection tracking state. My understanding is: If for some reason conntrack doesn't think it's the packet is "tracked" it could be grouped into "invalid" state. The problem is once it happens, .
ipvs should be fine. do you see similar issue in ipvs?
I also encountered this problem.

Have you solved it
is this a similar issue for ipvs?
The error is a very general networking issue, which could be caused by many different reasons. This specific cause can be reproduced by the It looks like you got an answer already there :)
Change:
jobObj, err := createJobWithDefaults(ctx, clientSet, ns.Name, &batchv1.Job{ Spec: batchv1.JobSpec{ CompletionMode: &mode, <del> Completions:    pointer.Int32(500), Parallelism:    pointer.Int32(500), </del> <ins> Completions:    pointer.Int32(100), Parallelism:    pointer.Int32(100), </ins> BackoffLimit:   pointer.Int32(0), }, })

Discussion:
seems we have a problem in branch 1.23, this test has been flaking for some time Originally posted by in
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 release /sig scheduling /kind flake
/assign
I see the log line for the desired outcome, but after the test has already timed out: And we do see a lot of throttling by APF. I'll just reduce the number of pods the test creates, only in 1.23, as other release seem fine.
just to keep ourselves honest: /remove-sig scheduling :smile:
still seeing this flake in release-1.23 (e.g. 3 runs in a row in , where CI is still running on go1.17)
this single test is failing 100% of runs in the 1.23 PR I'm currently working on
the cherry picks are still open
test has been green since the backports merged
Change:
package ipvs import ( <ins> "fmt" netutils "k8s.io/utils/net" </ins> "reflect" "testing" utilipvs "k8s.io/kubernetes/pkg/util/ipvs" utilipvstest "k8s.io/kubernetes/pkg/util/ipvs/testing" <del> netutils "k8s.io/utils/net" </del> ) func Test_GracefulDeleteRS(t *testing.T) {

Discussion:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)