jiebi/CodeConvo huggingface dataset:
Code change:
return &sha1SignatureChecker{ counterRaiser: &counterRaiser{ counter: counter, <ins> id:      "insecure-sha1", </ins> reason:  "uses an insecure SHA-1 signature", }, }

Related discussion:
text: adds the metrics. the release note on that issue describes the go change, links to go docs, describes use of the option, the new metrics, and the kube-apiserver logs what would you expect kubeadm to do with this? GODEBUG off by default and let users override GODEBUG on their own (is this possible)? GODEBUG by default on all clusters? GODEBUG by default only on upgrade? The risk of 1 is that a user upgrades without reading release notes and breaks a cluster that has SHA-1 certs in webhooks, etc The risk of 2 is that we propagate accepting insecure certificates longer, even in new clusters that we know don't have any pre-existing bad certs The risk of 3 is that it makes an upgraded 1.23 → 1.24 cluster and a new 1.24 cluster inconsistent
the majority of kubeadm users use kubeadm managed CA and certificates. there are less users that use external CA to sign their own certificates. sha1 attacks surfaced more than a before kubeadm's creation and Git hash collusion made the problem more known around 2017 - that was at a time when kubeadm did not support external CA. given these facts, an estimate on my side is that there are currently no kubeadm users that use sha1 certificates, but i would not exclude the possibility entirely. if such users exists, they are on they own and my vote goes for option 1, until they migrate their PKI to something secure. if the same users log tickets for us, our response would be "please use GODEBUG and migrate ASAP". all users should be able to see the notes in IMO, the PR needs an "action required" to appear on top of the release notes.
that's helpful, thanks agreed. weird, I set , but the label didn't get . the label manually.
and there's a way for them to set that envvar in kube-apiserver manifests when using kubeadm?
There's been a lot of intermittent github webhook delivery issues in the past few weeks or so, slash commands are going to be somewhat unreliable :/
they could use kubeadm patches to override the YAML manifest defaults - i.e. the contents of v1.Container -Env:
Code change:
in_pkg_root="$2" shift 2 ;; <ins> "--one-input-api") one_input_api="/$2" shift 2 ;; </ins> "--output-pkg-root") out_pkg_root="$2" shift 2

Related discussion:
text: function in script has following issues: function only supports file but we have multiple types file with name as in . Hence this function is not working in our case. For the mitigation there is already an open . I have asked for including our changes as well. We have multiple files under a for example and . Because of this for appears twice and it generates duplicate informers We only need unique elements before passing it to . I followed this approach for unique elements: We have packages under . Earlier we were generating client only for and . But with the new I am not able to do that. I am using the following call to function: It results in following flags to As there is no directory as , it doesnot generate anything. Is it still possible to call on specific folder as it was done with earlier scripts? One mitigation I can think of is to call function on whole and then remove the marker from the types for which genclient is not needed. But the issue is we won't be able to pass the flag for each pkg. function in script is not working as expected.
/sig api-machinery
/cc
/triage accepted
Hi . I knew that there were all sorts of clients out there doing all sorts of things with these scripts, so I am not surprised to find you. :) Do you have a PR which attempts to use kube_codegen, so I can repro your issues directly?
I think you have one too many in there Aside from that, the real problem here is that these old codegen tools make some deeeeeeep assumptions about the ability to string-join various arguments and get the right results. It's awful. I was trying to make it simpler in this script, which I did for all of the in-tree consumers, but out of tree people apparently don't always follow the same conventions. For example, we generate clients for every directory that requests it. For a reason I do not know, you have files like which say but you don't actually want a client? If you specify then it t
So this code expects that you generate an omnibus client. What if I add a flag, like which you can use to call it for each API to make distinct clients? In truth the codegen tools need to be fixed, but that has SO MUCH ripple I just can't right now.
Code change:
in_pkg_root="$2" shift 2 ;; <ins> "--one-input-api") one_input_api="/$2" shift 2 ;; </ins> "--output-pkg-root") out_pkg_root="$2" shift 2

Related discussion:
text: As the codegen was breaking us at several step, hence didn't prepared the PR.
Thanks for the PR. I have one more concern, is it possible to call and client-gen on the same pkg? With the current script, that is not possible because of the line It removes all the generated files first and then calls the . Hence the later clientset gen will remove the earlier generated clients.
Why are you generating a client for an internal version that isn't served?
My mistake. We need to stop using clients for internal versions.
Code change:
kubectl get pods "${kube_flags[@]}" kubectl get pod redis-master "${kube_flags[@]}" [ "$(kubectl get pod redis-master -o template --output-version=v1beta1 -t '{{ .id }}' "${kube_flags[@]}")" == "redis-master" ] <del> output_pod=$(kubectl get pod redis-master -o json --output-version=v1beta1 "${kube_flags[@]}") </del> <ins> output_pod=$(kubectl get pod redis-master -o yaml --output-version=v1beta1 "${kube_flags[@]}") </ins> kubectl delete pod redis-master "${kube_flags[@]}" before="$(kubectl get pods -o template -t "{{ len .items }}" "${kube_flags[@]}")" <del> echo $output_pod | kubectl create -f - "${kube_flags[@]}" </del> <ins> echo "${output_pod}" | kubectl create -f - "${kube_flags[@]}" </ins> after="$(kubectl get pods -o template -t "{{ len .items }}" "${kube_flags[@]}")" [ "$((${after} - ${before}))" -eq 1 ] kubectl get pods -o yaml --output-version=v1beta1 "${kube_flags[@]}" | grep -q "id: redis-master"

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:
ginkgo.Describe("Kubectl diff", func() { /* <del> Release : v1.18 </del> <ins> Release : v1.19 </ins> Testname: Kubectl, diff Deployment Description: Create a Deployment with httpd image. Declare the same Deployment with a different image, busybox. Diff of live Deployment with declared Deployment MUST include the difference between live and declared image. */ <del> ginkgo.It("should find diff in Deployment", func() { </del> <ins> framework.ConformanceIt("should check if kubectl diff finds a difference for Deployments", func() { </ins> ginkgo.By("create deployment with httpd image") deployment := commonutils.SubstituteImageName(string(readTestFileOrDie(httpdDeployment3Filename))) framework.RunKubectlOrDieInput(ns, deployment, "create", "-f", "-")

Related discussion:
text: and server-side dry-run are being promoted to stable features in 1.18. Conformance should ensure that cloud providers support these features. As a user, I expect to work, which requires that cloud providers for cloud default webhooks. Conformance would generally avoid cloud-specific issues like this one: This suggestion is from /area conformance
/sig testing /sig architecture
/wg apply
There are some good references for conformance tests in the conformance meeting notes:
once merges, we need to promote the e2e test to conformance in a follow up PR, in accordance to this doc: It seems like we meet the conformance test requirements. Here's the process specifically, which includes sig-arch and a review board group:
Code change:
} stats[path.Base(key)] = info } <del> return stats </del> <ins> return stats, cinfosByPodCgroupKey </ins> }

Related discussion:
text: <!-- 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 --For single node with hundreds and thousands of pods and containers, the cpu usage of kubelet becomes high, one bottleneck is the cadvisor stats provider as below: the method iterate all containerInfos for every podStats cause high cpu the method should not iterate allcontainerInfos for every podStats, use map instead Kubernetes version (use ): v1.19.4 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 node
/triage accepted
/assign
I’ve done an analysis on the code and this is what I have found, I believe we have two issues to address. There are multiple range loops being performed over v2.ContainerInfo / PodStat maps within the ListPodStatus method which can be contributing to the high cpu utilisation. The allInfos argument which is supplied to the getCadvisorContainerInfo function is a map which uses a cgroup path as the key, in order to find matching container info to podUID, processing of the keys in the map needs to be performed until a match is found. Examples of keys are as follows: /kubepods/burstable/podf9e3a173-1470-451a-9ca2-/d8426b82582fbcfae16085bc794c49769d3a9648bd5463976aca4071f9342754 /docker/2dfa17fc81e781212bcc26e189ebb724721fe097394b4de3cbeb7e069bf23290 My recommendation would be to apply the following updates: Refactor the getCadvisorContainerInfo function to allow for a filter and key type parameter to be supplied by the caller, this enables reducing the number of range loops being performed over the container info map by removing elements that are not required and the ability to set the key being used in the returned container infos map to enable fast lookup of container info.
Code change:
} stats[path.Base(key)] = info } <del> return stats </del> <ins> return stats, cinfosByPodCgroupKey </ins> }

Related discussion:
text: My initial thoughts are to use an enumeration which has two values KEYCGROUPPATH to provide backwards compatibility and KEYPODUID to enable fast lookups via podUID Refactor ListPodStats method to be more efficient in constructing the PodStats slice and taking into account the fast lookup via podUID I think this is the best approach instead of pushing the data structure implementation for the container info upstream to the cadviser clients, this will at least initially provide a better optimisation scoped within the kubelet/stats package and reduce other possible impacts to changing the cadvisor clients Please advise.
Just realized this looks like a duplicate issue and looking as fixed by PR Both this issue and were raised by Zac
/unassign
/close
You can't close an active issue/PR unless you authored it or you are a collaborator. <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
Didn't think I could close this, leaving this with
this will be automatically closed once the PR merges
Code change:
} done := func() bool { <del> // ensure the response body is closed before we reconnect, so that we reuse the same // TCP connection defer resp.Body.Close() </del> <ins> // Ensure the response body is fully read and closed // before we reconnect, so that we reuse the same TCP // connection. defer func() { const maxBodySlurpSize = 2 << 10 if resp.ContentLength <= maxBodySlurpSize { io.Copy(ioutil.Discard, &io.LimitedReader{R: resp.Body, N: maxBodySlurpSize}) } resp.Body.Close() }() </ins> retries++ if seconds, wait := checkWait(resp); wait && retries < maxRetries {

Related discussion:
text: From the recent runs of different scalability tests, I have a hypothesis that we are not reusing connections after "429" error is returned to the client. Here is description of one tests that I've seen failed: in 2000-node kubemark all watches were dropped at some point (that's a separate issue that is a bit unrelated here). happened next is that basically all watchers decided to do list + watch, and obvious a bunch of lists failed with 429 error (this is still expected). And we started retrying them. And this is still ok. that point, apiserver started consuming ~30 cores (which also isn't completely unexpected). what IS unexpected to me, is that looking into profile ~70% of the CPU (which was ~20 cores) were spend in "doFullHandshake". And this is a bit strange to me. Do we do something specific on 429 errors (e.g. close the connection) so that we won't be able to reuse it in the future? Or do you have any other hypothesis, why we were mostly doing "full handshakes" at that time?
On the server side, we can use on http server to get more info. Can we do the same thing on the client? I don't see anything obvious, but knowing when a connection from a client is closed (vs. terminated by the server, vs gracefully terminated via Connection: Close) might be useful in debugging these cases. The only thing I can think of is that the kubelet has multiple connections to the master, and so instead of reusing its pooled connections it's asking for new connections all at once (and blowing out the pool size in the client). Can we verify that the kubelet TCP connection pool size is greater than the default (which is 2?). Kubelet should definitely have a number of idle connections proportional to number of watches.
There's definitely a branch in the rest client where I think we don't fully read the response body on a 429. Though not explicitly stated in the docs, I think failing to read the entire body of a request also causes the TCP connection to not be reused. This is a code snippet from the HTTP client's redirect code: I can certainly add something like this to . I'm not sure if this is a problem for HTTP2 though.
Code change:
} done := func() bool { <del> // ensure the response body is closed before we reconnect, so that we reuse the same // TCP connection defer resp.Body.Close() </del> <ins> // Ensure the response body is fully read and closed // before we reconnect, so that we reuse the same TCP // connection. defer func() { const maxBodySlurpSize = 2 << 10 if resp.ContentLength <= maxBodySlurpSize { io.Copy(ioutil.Discard, &io.LimitedReader{R: resp.Body, N: maxBodySlurpSize}) } resp.Body.Close() }() </ins> retries++ if seconds, wait := checkWait(resp); wait && retries < maxRetries {

Related discussion:
text: was this running with HTTP2 enabled? I can't remember the status of that.
I'm pretty sure HTTP2 is off still. , krousey wrote:
Found the doc: I will go ahead and patch this.
Did we add a new error case that didn't catch this? Since this is the 3rd time we've fixed an edge case on reading the entire body, we should probably do what we can to make sure others don't show up.
It's the case where it's 429 or = 500 and there's a Retry-After header. I'm going to add it to the same place where we ensure that the body is closed so that it should always catch it.
k, thanks
Thanks for debugging it (and yes, http2 was switched off in my tests). And looking forward to see the fix. Thanks!
Code change:
import ( "fmt" "io/ioutil" <ins> "os" </ins> "path/filepath" "k8s.io/api/core/v1"

Related discussion:
text: Error Logs /kind bug /priority failing-test /priority critical-urgent /milestone v1.11 /assign cc Possible breaking change as per offline discussions.
- Timeline of breakage aligns with merge of , nothing else was in flight to cause it.
could this be the problem?
Is that's the problem, may be this will help
/sig cluster-lifecycle
/status approved-for-milestone
[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
you can't re-open an issue/PR unless you authored it or you are assigned to it. <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
https://k8s- https://k8s- both jobs are better now (past the failure where they keeled over before the test suite started). But both seem to have some test failures
we have one green run on each, so let's close this out. https://k8s- https://k8s- /close
Code change:
<ins> #!/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. # This command resizes a replication controller using kubectl. KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. KUBECTL="${KUBE_ROOT}/cluster/kubectl.sh" if [[ $# != 2 ]] ; then echo "usage: $0 <replication controller name> <size>" >&2 exit 1 fi rc="$1" size="$2" "${KUBECTL}" get -o json rc "$rc" | sed 's/"replicas": [0-9][0-9]*/"replicas": '"$size"'/' | "${KUBECTL}" update -f - rc "$rc" </ins>

Related discussion:
text: kubectl describe emits 1024 NULL characters prior to actual text. This prevents all text-based processing tools from working on its output. /cc
This has got to be due to:
(IRL discussion: there's no reason to pass 1024 0 bytes to NewBuffer.)
Fixing in PR .
Code change:
// Known values for the tag. const ( <del> tagValueTrue  = "true" tagValueFalse = "false" </del> <ins> tagValueTrue       = "true" tagValueFalse      = "false" tagExtensionPrefix = "x-kubernetes-" </ins> ) <ins> func getOpenAPITagValue(comments []string) []string { return types.ExtractCommentTags("+", comments)[tagName] } </ins> func hasOpenAPITagValue(comments []string, value string) bool { <del> tagValues := types.ExtractCommentTags("+", comments)[tagName] if tagValues == nil { return false } </del> <ins> tagValues := getOpenAPITagValue(comments) </ins> for _, val := range tagValues { if val == value { return true

Related discussion:
text: Background: kubectl and the Kubernetes reference docs both depend on the spec to operate on Kubernetes resources. The lacks important information required by kubectl and the docs. Usecase: kubectl can identify the patchStrategy and mergeKey for resource fields kubectl can identify the columns to print for on resources docs can parse and display the default value for fields docs can identify top-level objects Solution: Add items to the comment tag: Example: The long term plan is to remove the and struct tags once all code has been updated to use the swagger spec instead. Until then, comments should be for the struct tags and . Some verification process will need to be written to make sure the struct tags and comments remain in sync.
I think this wouldn't fall under sig-apps. cc
I would not do the columns stuff - we're moving get to the server side. Top level objects is already available in some form by the client - specifically the list that we use (should use) to get the swagger doc tells us what the top level type is (or is that for something like explain). Merge key, patch strategy, default values all belong as "real" attributes, although we had not necessarily intended those to be arguments to k8s:openapi-gen, but actual tags in their own right (like "+optional")
Thanks Is there a design proposal / eta for this? This is for generating the docs from swagger. Right now the list of top level resources for the docs to display is hardcoded in a . I would like to move the majority of the metadata out of the config file so that: same tool can generate reference docs for federated apiservers without writing a custom config. don't need to manually maintain and update the config for each release - e.g. adding new types I have no strong opinion about this as long as they appear in the swagger so it is possible right tools the can use this data. Can you comment on why openapi-gen vs specific tags?
Describe in the server makes sense to me. IIUC, just prints out a set of columns. Was the idea that the server would just print out the columns or return a list of column / values or something more complicated? No need to answer if it is in the issue / proposal already.