jiebi/CodeConvo huggingface dataset:
Change:
optional APIServiceStatus status = 3; } <ins> // APIServiceCondition describes the state of an APIService at a particular point </ins> message APIServiceCondition { // Type is the type of the condition. optional string type = 1;

Discussion:
Which jobs are failing: Which test(s) are failing: Job Reason for failure --- --- Since when has it been failing: 2019-02-11 Anything else we need to know: started failing with commit started failing with commit cc /kind failing-test /priority important-soon /sig api-machinery
Change:
pod.Spec.RestartPolicy = "Never" pod.Spec.Containers[0].Command = []string{"echo", "hi"} pod.Spec.Containers[0].Resources.Limits = v1.ResourceList{ <del> v1.ResourceCPU: resource.MustParse("1"), </del> <ins> v1.ResourceCPU: resource.MustParse("950m"), // leave a little room for other workloads </ins> } } createBatchPodWithRateControl(f, restartNeverPods, podCreationInterval)

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
"type": "integer" } }, <del> "type": "object" </del> <ins> "type": "object", "x-kubernetes-map-type": "atomic" </ins> }, "io.k8s.api.networking.v1beta1.IPAddress": { "description": "IPAddress represents a single IP of a single IP Family. The object is designed to be used by APIs that operate on IP addresses. The object is used by the Service core API for allocation of IP addresses. An IP address can be represented in different formats, to guarantee the uniqueness of the IP, the name of the object is the IP address in canonical format, four decimal digits separated by dots suppressing leading zeros for IPv4 and the representation defined by RFC 5952 for IPv6. Valid: 192.168.1.5 or 2001:db8::1 or 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 Invalid: 10.01.2.3 or 2001:db8:0:0:0::1",

Discussion:
I created an Ingress resource with a port number manually, and then tried to use an Operator with server-side apply to update the resource from a port number to a port name. This failed with the error message "cannot set both port name & port number". I expected the port number to be cleared as the operator would take over the ownership of the ServiceBackendPort. To simulate the behavior in the operator in a most simple example I use : ingress- ingress- This will print: It seems to me that the merge type for the struct ServiceBackendPort should to be set to "atomic" , so that the Operator updating the port should take over the whole struct, and two applications shouldn't update single fields in it. Red Hat OpenShift on AWS OS version of the client: NAME="Fedora Linux" VERSION="40 (Workstation Edition)" Linux 6.9.6-200.fc40.x8664 SMP PREEMPTDYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
/sig network
So, on one hand you made a problem when you used two different owners to manage one aspect of the object. On the other hand, I think you're right that it SHOULD work. Probably. is not a super common tag, and ingress way predates it, so no surprise it isn't used. I ACK the issue and reproduced it. I ran update-codegen and built a KinD cluster from HEAD.
this may be something you want to look at for DRA API - I didn't even realize this was a thing until today :)
The API uses for , which is very similar. So using it for LGTM. SSA will auto-migrate existing resources using once the change is released.
/triage accepted
"this" being "add "? I can see where this might be useful, probably on all one-of structs and perhaps on those containing a discriminator because otherwise SSA leaves fields set which should be cleared when some other owner takes over. Is this important enough to put into I don't see a big need for SSA in general and even less for SSA with different owners at the moment - this will change once we do more with status.
No, not urgent. This is the first time it has come up in my awareness ever. But now that I know about it, I could see how it applies to dra.

Thank to everyone involved here to resolve this! This will make things simpler in the Keycloak operator once it is released.
Thanks for filing a good (and easy to fix :) bug. Easy repro means we can jump on it.
Change:
[Kustomize](https://github.com/kubernetes-sigs/kustomize) version in kubectl had a jump from v2.0.3 to [v4.0.5](https://github.com/kubernetes/kubernetes/pull/98946). Kustomize is now treated as a library and future updates will be less sporadic. <del> ### Default Container Labels </del> <ins> ### Default Container Annotation </ins> <del> Pod with multiple containers can use `kubectl.kubernetes.io/default-container` label to have a container preselected for kubectl commands. More can be read in [KEP-2227](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2227-kubectl-default-container/README.md). </del> <ins> Pod with multiple containers can use `kubectl.kubernetes.io/default-container` annotation to have a container preselected for kubectl commands. More can be read in [KEP-2227](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2227-kubectl-default-container/README.md). </ins> ### Immutable Secrets and ConfigMaps

Discussion:
is wrong as it says default label can be specified, but KEP and other lines of changelog mentions annotation. Changelog is correct and consistent about default container feature for kubectl. I'm still not able to get this feature to work actually for . Kubernetes version (use ): v1.21.0
/triage accepted thanks for reporting early!
/remove-kind bug /kind documentation
/sig release
Change:
. "github.com/onsi/ginkgo" . "github.com/onsi/gomega" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests
Change:
"reflector_test.go", "shared_informer_test.go", "store_test.go", <ins> "thread_safe_store_test.go", </ins> "undelta_store_test.go", ], embed = [":go_default_library"],

Discussion:
What happened: Consider this use case, a k8s cluster with many short lived name spaces with a high cardinality. (Think UUIDs). Over time, some of the indices contain string sets for each name space with no objects in the backing string sets; which are never reused. Leads to process memory increasing over time until the process exceeds available memory. Potentially causing issues as an api-server or controller is terminated by the operating system. What you expected to happen: Process memory does not increase unbounded as the number of unique items then deleted from a thread safe map, causing indices to hold on to zero length string sets for the key. This could be mitigated when an index's string set for a key is empty, that string set is removed from the index. How to reproduce it (as minimally and precisely as possible): Thanks to for this reproduction code: Anything else we need to know?: Can be mitigated with the following patch against master at : has a code path for creating sets that don't exist, so if a set is temporarily reduced to zero; it will be re-created as if it was the initial case where the set was never created. Here's an apiserver pprof heap base png from a clean start for a test case of ≈800k name space create/delete in kube v1.14.7: Note the increase in heap utilisation from base of and nodes in the hot path. Similar increases were observed in v1.13.11 and v1.15.5. Same as above, but with the suggested fix and ≈100k name space create/delete: Note lack of and nodes in the hot path. (Was not able to directly attach the images to this issue due to Something went really wrong, and we can't process that file.) Environment: Kubernetes version (use ): Issue reproduced in v1.13.11, v1.14.7, 1.15.5 directly by adding/deleting namespaces. Above mitigation directly tested against a v1.14.7 cluster.
/sig api-machinery
Edit: I found threadSafeMap.updateIndices() - was searching with misspelled func name.
I'm not sure I follow, but is still present -
Nah, my bad; didn't spell the method right originally in the text.

One option is to mark the time when set becomes empty: We can clean Index entry when certain period has passed since the set becomes empty.
I really don't think that solution is a viable and adds unneeded complexity. You would then need to have something running in the background to prune empty sets. The solution proposed in the original post is the most straight forward, when the set is empty - delete it. If something is then created that needs the set, it will be recreated when needed.
I think that is fine.
Change:
for i := 0; i < rss.offset; i++ { at := (start + i) % rss.offset if allocated.Bit(at) == 0 { <del> return i, true </del> <ins> return at, true </ins> } } return 0, false

Discussion:
In a enabled cluster, Kubernetes assigns duplicate IP addresses when the dynamic block is exhausted. I expected all clusterIPs are uniquely assigned. a enabled Kubernetes v1.24 cluster with a small service-cluster-ip-range. I confirmed on the minikube with the following command. services until the dynamic block is exhausted. see some clusterIPs are duplicated. No response <details</details<detailsminikube v1.25.2 </details<details</details<details</details<details</details<details</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
When the dynamic block is exhausted, we expect the service creation to fail with an error message like "No IP address available", right?
According to , Dynamically IP assignment will use the upper band by default, once this has been exhausted it will use the lower range. So I think using the reserved block (the lower range) is expected behavior
/sig network
upps /assign
/assign great catch, thanks
Change:
}, }, }, <ins> InitContainers: []v1.Container{ { Resources: v1.ResourceRequirements{ Requests: requests, Limits:   limits, }, }, }, </ins> }, } }

Discussion:
The function removeMissingExtendedResources() located at , is designed to remove any extended resources from a container’s requests that are not found in nodeInfo.Allocatable before the pod is admitted. This is necessary to support cluster-level resources, which are extended resources that are unknown to nodes. However, this function only removes missingExtendedResources from the container’s requests, and does not process the requests of initContainers. This could lead to issues, as initContainers might request resources that do not exist on the node, which could result in the pod failing to be admitted or other unforeseen issues. As such, it may be necessary to refine the removeMissingExtendedResources() function to also handle initContainer’s requests. Refine the removeMissingExtendedResources() function to also handle initContainer’s requests. Create a pod that requests cluster-level extended resources in both the container and InitContainer. No response The problem persists in the latest version. <details</details<details</details<details</details<details</details
/sig node
/triage accepted /priority important-longterm
Change:
return err } // For connection errors and apiserver shutdown errors retry. <del> if net.IsConnectionReset(err) || net.IsConnectionRefused(err) { </del> <ins> if net.IsConnectionReset(err) { </ins> // For the purpose of retry, we set the artificial "retry-after" response. // TODO: Should we clean the original response if it exists? resp = &http.Response{

Discussion:
/kind bug changed behavior of client-go on connection refused errors, which changed a short wait and an "invalid host/port" error into a long retry wait and a confusing "internal server" error /assign Originally posted by in
/sig api-machinery
/milestone v1.18
I linked
Hello, bug-triage here. Just want to make sure we are still staffed and on-track for v1.18 code freeze
thanks, I will get to this tomorrow.
gentle ping
Change:
set -e source "${KUBE_ROOT}/hack/lib/init.sh" <ins> kube::util::ensure-gnu-sed </ins> function usage { echo "This script starts a local kube cluster. "

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: After running (on master branch), a new file named left as a surprise. and the file is not matched by git ignore so it's tracked by git which is really disturbing. I tried to find out where it's created but failed. Any one has a context w/ it? Environment: OS (e.g. from /etc/os-release): Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASEX8664 x86_64
/sig instrumentation
the only piece of code in local-up-cluster that touches the file is
can't reproduce this. Two questions: Can you see this everytime? What is the SHA of the commit on master when you tried this? Can check with that too.
finally i realize that the cause is command is built receiving different flags between Linux and OSX. on Linux, you'll find that for linux sed the is explained as: '--in-place[=SUFFIX]' This option specifies that files are to be edited in-place. GNU 'sed' does this by creating a temporary file and sending output to this file rather than to the standard output.(1). so the is optional. but for OSX, it is: Edit files in-place, saving backups with the specified extension. If a zero-length extension is given, no backup will be saved. It is not recommended to give a zero- length extension when in-place editing files, as you risk corruption or partial content in situations where disk space is exhausted, etc. the difference is that on OSX, flag is requiring a variable , so when we're using on OSX in the script: the which is supposed to be received as a flag will be a suffix for the backup file. then the magic happened.will raise a fix for this. /assign
linking the difference between and
Change:
fcmd := fakeexec.FakeCmd{ CombinedOutputScript: []fakeexec.FakeCombinedOutputAction{ func() ([]byte, error) { return []byte("dummy device have been created"), nil }, <ins> func() ([]byte, error) { return []byte(""), nil }, </ins> }, } fexec := &fakeexec.FakeExec{ CommandScript: []fakeexec.FakeCommandAction{ func(cmd string, args ...string) exec.Cmd { return fakeexec.InitFakeCmd(&fcmd, cmd, args...) }, <ins> func(cmd string, args ...string) exec.Cmd { return fakeexec.InitFakeCmd(&fcmd, cmd, args...) }, </ins> }, LookPathFunc: func(cmd string) (string, error) { return cmd, nil }, }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? /kind bug What happened: In ipvs proxy mode, most service functions like "nodeport/loadbalance" is realized by the association of iptables/ipset/ipvs, yet most ipvs proxier ut only verified ipvs rules, which can't ensure service is functional. What you expected to happen: Check both ipvs rules and iptables chains/rules, ipset entries in ipvsproxier ut.
/sig network /area ipvs /assign
What's the current UT coverage number?
Current is 50.2%.
So, can we achieve 70%?
Yeah, we can do that, and that's definitely necessary.
Change:
"STANDARD_D15_V2":        64, "STANDARD_D16AS_V4":      32, "STANDARD_D16A_V4":       32, <ins> "STANDARD_D16DS_V4":      32, "STANDARD_D16D_V4":       32, </ins> "STANDARD_D16S_V3":       32, "STANDARD_D16_V3":        32, "STANDARD_D1_V2":         4, "STANDARD_D2":            8, "STANDARD_D2AS_V4":       4, "STANDARD_D2A_V4":        4, <ins> "STANDARD_D2DS_V4":       4, "STANDARD_D2D_V4":        4, </ins> "STANDARD_D2S_V3":        4, "STANDARD_D2_V2":         8, "STANDARD_D2_V2_PROMO":   8,

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
accBody: "X-Muffins-Or-Cupcakes: muffins", }, { <ins> handler: headerEchoHandler, reqHeaders: http.Header{ "User-Agent": {"foo/1.0"}, }, health:  probe.Success, accBody: "User-Agent: foo/1.0", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "User-Agent": {""}, }, health:  probe.Success, notBody: "User-Agent", }, { handler:    headerEchoHandler, reqHeaders: http.Header{}, health:     probe.Success, accBody:    "User-Agent: kube-probe/", }, { </ins> // Echo handler that returns the contents of Host in the body handler: func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200)

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
// NOTE: Anything passed to DockerService should be eventually handled in another way when we switch to running the shim as a different process. func NewDockerService(client dockertools.DockerInterface, seccompProfileRoot string, podSandboxImage string, streamingConfig *streaming.Config, <del> pluginSettings *NetworkPluginSettings, cgroupsName string, kubeCgroupDriver string) (DockerService, error) { </del> <ins> pluginSettings *NetworkPluginSettings, cgroupsName string, kubeCgroupDriver string, execHandler dockertools.ExecHandler) (DockerService, error) { </ins> c := dockertools.NewInstrumentedDockerInterface(client) ds := &dockerService{ seccompProfileRoot: seccompProfileRoot,

Discussion:
Either deprecate the nsenter exec handler, or add nsenter handling to the dockershim (after goes in). /cc
I vote for deprecating the nsenter exec handler for docker. has been the default exec handler since kubernetes pre-1.0. Is there any reason (or use case) for keeping the pluggable exec handler? Another question is that whether we can drop exec in one release, or we need to provide support in CRI for at lease one more release. /cc
+1 for docker exec.
I suggest deprecating docker nsenter exec in a long term, but to achieve that, we need to follow the deprecation policy. The first thing we need to address is marking this flag (--docker-exec-handler, default: native) being deprecated:
Also there are several issues raised before which are related to the issue of docker exec in various versions. The engineer even suggested to switch the default mechanism is docker nsenter exec. One of the examples is
Now let's narrow down to the CRI scope, and below is my 2 cents: 1) Can we mark the flag deprecated in 1.6? 2) Drop the support in CRI in 1.6? Inform the kubernetes users with this decision along CRI announcement being scheduled sometimes in February? 3) Drop the support completely from Kubernetes unless there are real use cases coming up.
We'll have to tell the users that they need to disable CRI in order to use the nsenter exec plugin. could you give a quick estimate about the amount of work required to add support for nsenter exec in dockershim? Thanks.
Talked to offline. I'll Add support nsenter as exec in dockershim Mark the flag as deprecated.
Change:
timeOfLastSync                  time.Time volumesFailedReconstruction     []podVolume volumesNeedUpdateFromNodeStatus []v1.UniqueVolumeName <del> volumesNeedReportedInUse        []v1.UniqueVolumeName </del> } func (rc *reconciler) unmountVolumes() {

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign