jiebi/CodeConvo huggingface dataset:
Change:
} func (h *EtcdHelper) listEtcdNode(key string) ([]*etcd.Node, uint64, error) { <del> result, err := h.Client.Get(key, false, true) </del> <ins> result, err := h.Client.Get(key, true, true) </ins> if err != nil { index, ok := etcdErrorIndex(err) if !ok {

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
} fw.updateReader = startReading(fw.updateChan) fw.fakeKubelet = &fakeKubelet{} <del> fw.serverUnderTest = &Server{ host:    fw.fakeKubelet, updates: fw.updateChan, } </del> <ins> server := NewServer(fw.fakeKubelet, fw.updateChan) fw.serverUnderTest = &server </ins> fw.testHTTPServer = httptest.NewServer(fw.serverUnderTest) return fw }

Discussion:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone
Change:
// +genclient:nonNamespaced // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object // +k8s:prerelease-lifecycle-gen:introduced=1.7 <del> // +k8s:prerelease-lifecycle-gen:deprecated=1.19 </del> <ins> // +k8s:prerelease-lifecycle-gen:deprecated=1.16 // +k8s:prerelease-lifecycle-gen:removed=1.22 </ins> // +k8s:prerelease-lifecycle-gen:replacement=apiextensions.k8s.io,v1,CustomResourceDefinition // CustomResourceDefinition represents a resource that should be exposed on the API server.  Its name MUST be in the format // <.spec.name>.<.spec.group>. <del> // Deprecated in v1.16, planned for removal in v1.19. Use apiextensions.k8s.io/v1 CustomResourceDefinition instead. </del> <ins> // Deprecated in v1.16, planned for removal in v1.22. Use apiextensions.k8s.io/v1 CustomResourceDefinition instead. </ins> type CustomResourceDefinition struct { metav1.TypeMeta   `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`

Discussion:
The following code snippet is very confusing: Is v1beta1 deprecated in 1.16 or 1.19? Is it to be removed in 1.19 or 1.22? Please clarify the exact versions so the many users of CRD v1beta1 APIs know what to do.
/sig api-machinery
/kind deprecation
/unkind feature
Deprecated in 1.16. Planned to be removed in 1.22. We'll update the docs to be consistent before 1.19 is released.
/assign
Change:
reasons = append(reasons, &PredicateFailureError{r.Name, r.Reason}) } } <ins> // Check taint/toleration except for static pods if !types.IsStaticPod(pod) { _, isUntolerated := corev1.FindMatchingUntoleratedTaint(nodeInfo.Node().Spec.Taints, pod.Spec.Tolerations, func(t *v1.Taint) bool { // Kubelet is only interested in the NoExecute taint. return t.Effect == v1.TaintEffectNoExecute }) if isUntolerated { reasons = append(reasons, &PredicateFailureError{tainttoleration.Name, tainttoleration.ErrReasonNotMatch}) } } </ins> return reasons }

Discussion:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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
/remove-lifecycle stale PR in review:
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
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:
} wg.Add(1) go func(extIndex int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_extender").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_extender").Dec() wg.Done() }() </ins> prioritizedList, weight, err := extenders[extIndex].Prioritize(pod, nodes) if err != nil { // Prioritization errors from extender can be ignored, let k8s/other extenders determine the priorities

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign
Change:
## Changelog since v1.14.4 <del> **No notable changes for this release** </del> <ins> * Fix CVE-2019-11249: Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal ([#80436](https://github.com/kubernetes/kubernetes/pull/80436)) * Fix CVE-2019-11247: API server allows access to custom resources via wrong scope ([#80750](https://github.com/kubernetes/kubernetes/pull/80750)) See also the [security announcement for this release](https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM). </ins> # v1.14.4

Discussion:
What would you like to be : The release notes state "No notable changes for this release": However it turns out these releases fix important security problems: Why is this needed: If people track releases in, for example, GitHub and then use the release notes to see what's changed, they will totally miss that important security problems have been fixed in these releases. People should not have to look in multiple places to find news of such fixes. The current practice risks people not upgrading because there were "no notable changes" and being oblivious to the risks they run.
I expect this is one for and probably others but I don't really have any clue who.
/sig release This has to do with the timing of cutting the releases vs sending the announcements. The notices were included in the announcement, but not in the generated md files. /assign can you open a PR to update those?
Looks like they put it in the email and the group, but not the release notes. !topic/kubernetes-security-announce/vUtEcSEY6SM/discussion
Just opened a PR to fix this: (I only noticed that this issue was already assigned after committing my changes, hope that's OK)
Thanks that PR looks exactly like what I'm after for this particular update!
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. .PHONY: cauldron TAG = 1.0 cauldron: GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -a -installsuffix cgo --ldflags '-w' cauldron.go container:	cauldron docker build --pull -t kubernetes/cauldron:$(TAG) . push: docker push kubernetes/cauldron:$(TAG) rc: kubectl create --validate -f cauldron-rc.yaml stop: kubectl delete rc cauldron get: kubectl get rc,pods -l app=cauldron scale20: kubectl scale rc cauldron --replicas=20 scale1: kubectl scale rc cauldron --replicas=1 clean: rm -rf cauldron </del>

Discussion:
We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) Apparently the repo is referenced for docker push and pull in It's unclear to me whether we have broken anything, or if this is dead code. I would use to find out if this is referenced anywhere (aside from sundry vendor dirs) If dead code: remove it If used: move to test/e2e/images and follow the same pattern there used to push to /sig testing /area test /wg k8s-infra /priority important-soon /help /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : We've deleted all repos from Docker Hub and will be retiring the org/user (ref: ) /area test /wg k8s-infra /priority important-soon /good-first-issue I believe this is a pretty straightforward issue and am happy to review whatever PR's are made for it 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:
</tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">targetPort</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod&#8217;s container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: <a href="http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service">http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service</a></p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod&#8217;s container ports. If this is not specified, the value of the <em>port</em> field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the <em>port</em> field. More info: <a href="http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service">http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service</a></p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td> <td class="tableblock halign-left valign-top"></td>

Discussion:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.
Change:
return ${success} } <del> if [ ! $(nc -vz "${host} ${port}") ]; then </del> <ins> if [ ! $(nc -vz "${host}" "${port}") ]; then </ins> kube::log::status "${host}:${port} is free, proceeding..." return ${success} else

Discussion:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.
Change:
driver2 := &storagev1.CSIDriver{ ObjectMeta: metav1.ObjectMeta{ Name: "inline-driver-" + string(uuid.NewUUID()), <ins> Labels: map[string]string{ "test": f.UniqueName, }, </ins> }, Spec: storagev1.CSIDriverSpec{

Discussion:
https://k8s- CSIInlineVolumes should support ephemeral VolumeLifecycleMode in CSIDriver API 8/5 https://k8s- No response /sig storage
/triage accepted
/assign
Change:
func parseEnvs(envArray []string) ([]api.EnvVar, error) { envs := []api.EnvVar{} for _, env := range envArray { <del> parts := strings.Split(env, "=") if len(parts) != 2 || !validation.IsCIdentifier(parts[0]) || len(parts[1]) == 0 { </del> <ins> pos := strings.Index(env, "=") if pos == -1 { </ins> return nil, fmt.Errorf("invalid env: %v", env) } <del> envVar := api.EnvVar{Name: parts[0], Value: parts[1]} </del> <ins> name := env[:pos] value := env[pos+1:] if len(name) == 0 || !validation.IsCIdentifier(name) || len(value) == 0 { return nil, fmt.Errorf("invalid env: %v", env) } envVar := api.EnvVar{Name: name, Value: value} </ins> envs = append(envs, envVar) } return envs, nil

Discussion:
I'm running application with several env variables. One of them has a key ending with ==. Another variable has a comma separated list of email addresses. While perfectly valid on *nix and windows, we can't pass these values into Kubernetes run command. It fails with "error: invalid env:" Example command: The parsing in should be more robust
I volunteer myself to fix this.
Maybe they can be passed from file? I mean s'rsly.. you need to lits 20 variables by hand?? I've specified them in yaml file already, but kubectl-run have no way to specify it.. without this, deployment is totally impossible when you need to run migrations first!
Change:
case "GetInodes": _, err = GetInodes(testcase.path) default: <del> t.Errorf("Case %v (%s, %v) unknown operation %s", seq, testcase.path, true, testcase.op) </del> <ins> t.Errorf("Case %v (%s, %s, %v) unknown operation %s", seq, testcase.name, testcase.path, true, testcase.op) </ins> return true } if err != nil && testcase.expectsSetQuota { fail = true <del> t.Errorf("Case %v (%s, %v) %s expected to clear quota but failed %v", seq, testcase.path, true, testcase.op, err) </del> <ins> t.Errorf("Case %v (%s, %s, %v) %s expected to clear quota but failed %v", seq, testcase.name, testcase.path, true, testcase.op, err) </ins> } else if err == nil && !testcase.expectsSetQuota { fail = true <del> t.Errorf("Case %v (%s, %v) %s expected not to clear quota but succeeded", seq, testcase.path, true, testcase.op) </del> <ins> t.Errorf("Case %v (%s, %s, %v) %s expected not to clear quota but succeeded", seq, testcase.name, testcase.path, true, testcase.op) </ins> } return fail }

Discussion:
When sizeLimit is specified subsequent invocations will fail with the message: No error should be raised. Create a pod with emptyDir and sizeLimit with FSQuotaMonitoring enabled, MountVolume.SetUp is called again only if the first iteration takes longer then the actual reconciler loop interval (100ms). No response <detailsversion.Info{Major:"1", Minor:"27+", GitVersion:"v1.27.0-beta.0.87+", GitCommit:"", GitTreeState:"clean", BuildDate:"2023-04-10T09:05:56Z", GoVersion:"go1.20.2", Compiler:"gc", Platform:"linux/amd64"} </details<detailsSelf-managed cluster in Azure </details<detailsNAME="Red Hat Enterprise Linux" VERSION="9.1 (Plow)" ID="rhel" IDLIKE="fedora" VERSIONID="9.1" Linux test-master-0 6.3.0-rc3 SMP PREEMPTDYNAMIC Thu Apr 6 20:44:15 UTC 2023 x8664 x8664 x8664 GNU/Linux </details<detailsContainerd 1.6.15 </details<detailsCNI: CANAL 3.24.1 </details
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 node
May you please share more information? Which version of Kubernetes you are using? OS version etc.
The problem occurs with the latest master branch, I updated the initial post with versions.
Thank you.
Change:
Command:  []string{"tar", "cf", "-", t.src.File.String()}, Executor: &exec.DefaultRemoteExecutor{}, } <del> if t.o.MaxTries > 0 { </del> <ins> if t.o.MaxTries != 0 { </ins> options.Command = []string{"sh", "-c", fmt.Sprintf("tar cf - %s | tail -c+%d", t.src.File, n)} }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Trying to copy a large file from a container via kubectl cp with the new flag results in the following error: I executed the following command: EDIT: The command executes and the file is copied. However, the resulting file is somehow corrupted: However, the files have exactly the same size locally and on the pod: Also, the command exits with non-zero code and thus scripts may stop or abort at this point. What you expected to happen: The large file to be downloaded from the container completely and unharmed. Exit code 0 only if copy was successful How to reproduce it (as minimally and precisely as possible): Add a large file (mine was ~150M) to any location in the pod (preferrably a tar file). Execute kubectl cp to download the large file and use the flag. Try to untar the resulting file Anything else we need to know?: Related to Issue . I only experience this issue if I see kubectl doing at least one retry. Environment: Kubernetes version (use kubectl version): server v1.20.12, client v1.23.1 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Kernel (e.g. uname -a): Install tools: Others:
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 cli
tar: Removing leading `/' from member names so cancel first "/" from "" like this: k cp --retries=-1
Thanks for the hint. The warning is a and I was just ignoring it in my case. This issue is about the error message and the command exiting with a non-zero exit code.
I just updated the issue description, we see the tar files being corrupted after kubectl did at least one retry
/assign atiratree
Is it correct to start at position bytesRead+1? Or should this be bytesRead instead?

For example, if 1 byte was read (position 0), we would want to resume from position 1, not position 2. Just a thought, I haven't really looked at what initReadFrom does.
It should be correct since the byte start of tail (part of implementaion of initReadFrom) and bytes read match. Meaning that when we read 10 bytes we want to start reading 11th one. The actual problem was that we were running a wrong command when -1 retries is used: please see
Change:
{ Name: logVolume, VolumeSource: v1.VolumeSource{ <del> HostPath: &v1.HostPathVolumeSource{Path: path.Dir(tmpLogFile)}, </del> <ins> EmptyDir: &v1.EmptyDirVolumeSource{}, </ins> }, }, {

Discussion:
Leads to this avc: In general, HostPath volumes in tests are bad news for selinux.