jiebi/CodeConvo huggingface dataset:
Change:
__kubectl_parse_get "${nouns[${#nouns[@]} -1]}" } <ins> __kubectl_get_resource_pod() { __kubectl_parse_get "pod" } </ins> # $1 is the name of the pod we want to get the list of containers inside __kubectl_get_containers() {

Discussion:
TODOs: Last updated on Sept 2 by Janet [x] kubectl label - suggest a resource type [x] kubectl get and delete also use kubectl.NewHumanReadablePrinter to get the resources back, thus should be fixed as well. [x] kubectl exec - suggest the pod name [x] kubectl rolling-update - suggest the rc name [x] check that is doing the right thing [x] Distribute with kubernetes binaries [x] Put information about kubectl completion in user guide [x] docs/getting-started- Recently some users reported that there is no completion for the kubectl command. But there is. Unfortunately it is not documented how to install it. I found that all needs to be done is to: (or maybe just copy this file into /etc/bash_completion.d/) This information should be put into the user guide (maybe it is there - I just can't find it) I think it should be included for instance here: docs/getting-started- There are also some minor issues: does not suggest the rc name does not suggest the pod name does not suggest a resource type (maybe this is ok because we can give --overwrite here)
It looks like the bash-completion file is not distributed with kubernetes binaries:
:+1: This should definitely be provided with the binaries.
Good suggestions. Cc
, please cofirm that the bash completion file is distributed with k8s binaries: namely contrib/completions/bash/kubectl For me it looks like it isn't.
cc
I confirmed and it isn't.
TODOs: [x] kubectl label - suggest a resource type [x] kubectl get and delete also use kubectl.NewHumanReadablePrinter to get the resources back, thus should be fixed as well. [x] kubectl exec - suggest the pod name [x] kubectl rolling-update - suggest the rc name [x] check that is doing the right thing [x] Distribute with kubernetes binaries [x] Put information about kubectl completion in user guide [x] docs/getting-started- Last updated on Sept 2
Maybe add: check that is doing the right thing....
Thanks for the suggestion. Checklist updated.
Depending on where you want it in the tarball, is a good place to start. You can use and then iterate on until you're comfortable with the changes.

(If I'm making packaging changes, I'll frequently start by dumping the sorted output of that command into a file, then later diff against it to make sure I got exactly the change I wanted.)
Right now both and brings up all containers that has. Since is optional (the without -c way is supported as legacy behavior), this is expected. I'm not sure how to force the bash completion to print instead of container names when since flag isn't set as required in code.
Change:
} // ServiceBackendPort is the service port being referenced. <ins> // +structType=atomic </ins> type ServiceBackendPort struct { // name is the name of the port on the Service. // This is a mutually exclusive setting with "Number".

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:
create-static-ip "${MASTER_NAME}-ip" "${REGION}" MASTER_RESERVED_IP=$(gcloud compute addresses describe "${MASTER_NAME}-ip"  --project "${PROJECT}" --region "${REGION}" -q --format='value(address)') <del> KUBELET_APISERVER="${MASTER_RESERVED_IP}" </del> <ins> if [[ "${REGISTER_MASTER_KUBELET:-}" == "true" ]]; then KUBELET_APISERVER="${MASTER_RESERVED_IP}" fi </ins> KUBERNETES_MASTER_NAME="${MASTER_RESERVED_IP}" create-certs "${MASTER_RESERVED_IP}"

Discussion:
Kubernetes version (use ): HEAD Environment: GCE What happened: When I set up I can see the following message: What you expected to happen: master should not be registered
cc
Looks like the env var isn't being respected any longer by the master scripts (but the logic for # of expected nodes did adjust correctly).
/cc I think this may have broken in because it which unconditionally sets the field that tells a kubelet to register with the master outside of the guard that checks .
Fix in progress: . There was a problem caused by unconditional setting on the master in .
Change:
configuration data, with the running set of containers by starting or stopping Docker containers.`, Run: func(_ *Server, _ []string, stopCh <-chan struct{}) error { <ins> if s.ExperimentalDockershim { return app.RunDockershim(&s.KubeletFlags, &s.KubeletConfiguration) } </ins> return app.Run(s, nil) }, }

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?: What happened: kubelet has support for running in dockershim-only mode via a hidden flag named , but this flag is ignored when kubelet is run using hyperkube binary, e.g. . What you expected to happen: I expected to have the same effect with hyperkube as it has with 'plain' kubelet binary. How to reproduce it (as minimally and precisely as possible): Try to run kubelet in dockershim mode using hyperkube binary: It'll start in normal mode instead. Anything else we need to know?: We use dockershim server for CRI Proxy part of project. Virtlet is a CRI implementation for running VMs as pods, and thanks to that CRI proxy mechanism it's deployed as a DaemonSet itself. Unfortunately lack of flag in hyperkube causes some deployment difficulties and as of now we have to import code from kubelet to run our own dockershim server. Environment: Kubernetes version (use ): v1.8.1 I can fix this one myself if it's agreed that the change is useful.
go for it. the debate can be on the PR :)
/assign
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : 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:
imagePullTest(image, false, v1.PodPending, true, false) }) <del> ginkgo.It("should not be able to pull non-existing image from gcr.io [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.Invalid) imagePullTest(image, false, v1.PodPending, true, false) }) ginkgo.It("should be able to pull image from gcr.io [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.DebianBase) isWindows := false if framework.NodeOSDistroIs("windows") { image = imageutils.GetE2EImage(imageutils.WindowsNanoServer) isWindows = true } imagePullTest(image, false, v1.PodRunning, false, isWindows) }) ginkgo.It("should be able to pull image from docker hub [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.Alpine) isWindows := false if framework.NodeOSDistroIs("windows") { // TODO(claudiub): Switch to nanoserver image manifest list. image = "e2eteam/busybox:1.29" isWindows = true } imagePullTest(image, false, v1.PodRunning, false, isWindows) </del> <ins> ginkgo.It("should be able to pull image [NodeConformance]", func() { // NOTE(claudiub): The agnhost image is supposed to work on both Linux and Windows. image := imageutils.GetE2EImage(imageutils.Agnhost) imagePullTest(image, false, v1.PodRunning, false, false) </ins> }) ginkgo.It("should not be able to pull from private registry without secret [NodeConformance]", func() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:
Change:
stopCh = make(chan struct{}) tracker = newPodTracker() <del> newPods, controller = controllerFramework.NewInformer( </del> <ins> newPods, controller = controllerframework.NewInformer( </ins> &cache.ListWatch{ ListFunc: func() (runtime.Object, error) { return framework.Client.Pods(ns).List(labelSelector, fields.Everything())

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
// ServiceAnnotationLoadBalancerInternal is the annotation used on the service // to indicate that we want an internal ELB. <del> // Currently we accept only the value "0.0.0.0/0" - other values are an error. // This lets us define more advanced semantics in future. </del> const ServiceAnnotationLoadBalancerInternal = "service.beta.kubernetes.io/aws-load-balancer-internal" // ServiceAnnotationLoadBalancerProxyProtocol is the annotation used on the

Discussion:
Kubernetes version (use ): v1.4.6 Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS v1235.2.0 Kernel (e.g. ): 6-coreos-r1 SMP Wed Dec 7 00:29:42 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux What happened: When creating a service-type loadBalancer, adding creates an internal ELB, but the only allowed value for is 0.0.0.0/0. This limitation prevents you from specifying custom CIDR range for your hybrid cloud (Direct Connect to private data center) What you expected to happen: The limitation is unnecessary. Even in an AWS only scenario (no hybrid cloud), it makes sense to allow a CIDR range for a subnet where your calling services are deployed. How to reproduce it (as minimally and precisely as possible): Create a service-type loadBalancer and set loadBalancerSourceRanges to a value other than 0.0.0.0/0
Any update on this? Also, is anyone working on adding support for securityGroup?
any progress on this? I also really would like to have this flexibility in place for integrating k8s into an existing VPC.
Change:
package storage_test import ( <ins> "fmt" </ins> "reflect" "strconv" "testing"

Discussion:
cc
This is still hapening. Assigning Isaac for triage.
Three times in the last three days, BeforeSuite failed (filed ). Otherwise, just Namespaces [Serial] should delete fast enough (90 percent of 100 namespaces in 150 seconds) is just totally borked (filed ). what prevented you from triaging this yourself? It'd be good to know so I'm less in the critical path.
Sorry, I read this wrong. I was looking at the gke-serial suite. Triaging now.
It looks like massive failures are correlated extremely strongly with failure of Etcd failure [Disruptive] should recover from SIGKILL Every time that test passes, everything else (except ) passes; every time it fails, the whole suite goes south. Reassigning to for triage.
sorry for delegating the work to you, but I completely didn't have time to do it and nobody else hasn't volunteered to do it for a while. it seems you are the author of the test, so assigning you.
No problem Just wanted to make sure there wasn't some information missing.
I'm looking at this today
It looks like the token controller is not recovering from etcd failing. The test namespace is also stuck in a terminating phase. I'll continue to investigate
Actually lot's of watch related things are broken. I can create/delete objects in the api but watch is broken. Trying to establish a watch in this state causes: Restarting the apiserver fixes the problem. I can start a watch again: cc
Not particularly useful apiserver logs Also none of the components are trying to reestablish watches so I'm assuming that they still have watches open but are not receiving anything.
startCaching is trying to lock here, but something is holding the lock. I'm looking through a stack trace right now for the offender. This is exactly where I'd expect a problem to be from the description of "bringing etcd down and up repeatedly".
Ah I think what happened is, when etcd stays down, a List never successfully finishes, and therefore it never calls the OnReplace function, and therefore the lock is never unlocked, and therefore startCaching can't exit.

There's lots in apiserver log to support this: Additionally I manually looked through the stack trace and confirmed that all of the stuck calls to Watch are stuck waiting to RLock and not some point afterwards.
This is pretty bad, etcd going down for just a bit could freeze up apiserver until it is rebooted.
I think I can make a fix.
Thanks for looking into this.
Yeah, I repro'd in a UT. Fix coming shortly.
I assigned to but if anyone wants it merged sooner than monday, feel free to review.
Many thanks to for handing me a broken server to look at, it made this super easy to find.
Change:
continue case err == wait.ErrWaitTimeout: if watchEvent != nil { <del> return watchEvent.Object, false, wait.ErrWaitTimeout </del> <ins> return watchEvent.Object, false, errWaitTimeoutWithName </ins> } <del> return gottenObj, false, wait.ErrWaitTimeout </del> <ins> return gottenObj, false, errWaitTimeoutWithName </ins> default: return gottenObj, false, err }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : let's say I run If the deployment is comes up in time it tells me which deployment is up, but if it times out it doesn't tell me on which deployment/resource. Could it be Why is this needed: That would make it easier to use, and the information provided is the same irregardless on whether the condition is met or not
/sig cli
Sounds reasonable for me, i can take care of this one if someone from owners will approve it as a feature.
/assign Zyqsempai
GitHub didn't allow me to assign the following users: Zyqsempai. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Zyqsempai 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:
reason:  "FailedScheduling", pattern: make([]string, 2)} ep.pattern = append(ep.pattern, "MatchNodeSelector") <del> ep.pattern = append(ep.pattern, "No nodes are available") </del> <ins> ep.pattern = append(ep.pattern, "NoVolumeNodeConflict") </ins> for _, testVolType := range LocalVolumeTypes { It("should not be able to mount due to different NodeAffinity", func() {

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 /assign What happened: Looks like the event messaging has changed
Change:
switch { case storage.IsNotFound(err): return errors.NewNotFound(qualifiedResource, "") <del> case storage.IsUnreachable(err), storage.IsRequestTimeout(err): </del> <ins> case storage.IsUnreachable(err): </ins> return errors.NewServerTimeout(qualifiedResource, "list", 2) // TODO: make configurable or handled at a higher level case storage.IsInternalError(err): return errors.NewInternalError(err)

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
} func cleanFlags(s *KubeletServer) { <del> s.KubeConfig = utilflag.NewStringFlag(s.KubeConfig.Value()) </del> s.DynamicConfigDir = utilflag.NewStringFlag(s.DynamicConfigDir.Value()) s.KubeletConfigFile = utilflag.NewStringFlag(s.KubeletConfigFile.Value()) }

Discussion:
This will be the end of the deprecation period for --require-kubeconfig.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
ref
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
ExecStart=/opt/bin/kubelet  --address=0.0.0.0  --port=10250  <del> --hostname_override=$private_ipv4  </del> <ins> --hostname_override=${DEFAULT_IPV4}  </ins> --api_servers=<master-private-ip>:8080  --allow_privileged=true  --logtostderr=true 

Discussion:
Minor issues with 1) The examples rely on cloud vendor specific variables ($private_ipv4 ) 2) The wget command for kube-register always re-downloads
Change:
ginkgo.By("Validating /stats/summary") // Give pods a minute to actually start up. <del> gomega.Eventually(getNodeSummary, 1*time.Minute, 15*time.Second).Should(matchExpectations) </del> <ins> gomega.Eventually(getNodeSummary, 90*time.Second, 15*time.Second).Should(matchExpectations) </ins> // Then the summary should match the expectations a few more times. gomega.Consistently(getNodeSummary, 30*time.Second, 15*time.Second).Should(matchExpectations) })

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: NodeConformance is too rigid, and that makes it fail on certain platforms. It even For e.g the test right now assumes that it will always enter in the the condition here, but never accounts for the scenrio where the code might enter in , which is also a valid execution scenario. Which test(s) are failing: Summary API Tests - Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Anything else we need to know:
/sig node
Sample output of on CRIO running on Fedora CoreOS,
/assign /triage accepted /priority important-longterm /cc
Coming back to this.. should merge soonish. As soon as that happens then we can see if the test mentioned here improves.
In my test setup I noticed that end up being 0, and that causes the test to fail. Just to verify, I hard coded a value greater than 1000 there (because what the test case is expecting) and the test started passing. I will investigate more on why the values coming from cadvisor for filesytem usage is 0 sometimes.
Change:
func TestClient(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> ns := api.NamespaceDefault framework.DeleteAllEtcdKeys()

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.