jiebi/CodeConvo huggingface dataset:
Change:
klog.Errorf("Failed to create govmomi client. err: %+v", err) return err } <ins> setVCenterInfoMetric(connection) </ins> return nil } m := session.NewManager(connection.Client)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware
Change:
endpointsConfig.Channel("api"), ) <del> config.NodeRef = &api.ObjectReference{ </del> <ins> config.NodeRef = &v1.ObjectReference{ </ins> Kind:      "Node", Name:      hostname, UID:       types.UID(hostname),

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When testing , I found kube-proxy can not record event with following errors. What you expected to happen: No errors How to reproduce it (as minimally and precisely as possible): cc
I am still getting this with the latest build
, thanks for your feedback, I'll check it.
Change:
# NOTE: All functions that return lists should use newlines. # bash functions can't return arrays, and spaces are tricky, so newline # separators are the preferred pattern. <del> # To transform a string of newline-separated items to an array, use mapfile -t: # mapfile -t FOO <<< "$(kube::golang::dups a b c a)" </del> <ins> # To transform a string of newline-separated items to an array, use kube::util::read-array: # kube::util::read-array FOO < <(kube::golang::dups a b c a) </ins> # # ALWAYS remember to quote your subshells. Not doing so will break in # bash 4.3, and potentially cause other issues.

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --This issue was moved from What happened: building kubernetes with make fails on mac after What you expected to happen: building should not fail How to reproduce it (as minimally and precisely as possible): build from a mac Anything else we need to know?: mapfile is not available on macOS bash. we should have a version check at minimum if we're going to use unsupported features (some of the code already does this) cc
/sig release
Ugh. Does the containerized build at least still work on Mac? Ideally we'd stick to that as the recommended approach, since we can at least guarantee a correct environment. I guess this is really Apple's fault, for refusing to upgrade the bash version on Macs (so they can avoid GPL) - the default on most Macs is 3.2.57, which dates to 2007 according to this blog post: I don't personally think we should support something that old. None of our CI uses a bash that old. It's ripe for breakage. You can install a newer version of bash via homebrew.
the containerized build does not because this code runs on the host. we should put a version check then, so we get a more understandable error.
Up until this point we have supported it by using instead, macOS's old system bash is annoying, but errors from deep within our bash waste more time supporting confused developers
IIRC even in CI you ran into a bash version problem in fact just yesterday (?) we could add a snippet like this to the main build if we don't want to switch to :
I worry about requiring brew and can imagine some folks systems might be managed in a way that disallow this. Still it's reaaaaally painful having to debug and trying to keep things running with the crufty OSX dev userspace. Given there are multiple snippets of brew install suggestions, it would be better imho to put them in one common top level place (ie: )
fair, On systems with restricted at least should work, if that doesn't work i'd expect the setup is just too restrictive to build at all (?)

The check doesn't have to require homebrew per se either, even just "Sorry building on macOS is unsupported" is more helpful than:
Fix inbound:
/assign
Change:
health kubernetes {{ pillar['dns_domain'] }} in-addr.arpa ip6.arpa { pods insecure <ins> upstream </ins> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [Slow][Serial] Since when has it been failing: Failing since 6/10 at 16:58. . Decent chance that the failure is due to Testgrid link: Reason for failure: /cc /priority critical-urgent /kind failing-test /milestone v1.15 /cc
This is blocking the release /cc
I noticed in the it thinks it's testing 1.16 alpha:
/assign
should fix it. Sorry for the mess-up!
Change:
return nil } <ins> overwrite := cmdutil.GetFlagBool(cmd, "overwrite") </ins> helper := resource.NewHelper(info.Client, info.Mapping) <del> patcher := NewPatcher(encoder, decoder, info.Mapping, helper) </del> <ins> patcher := NewPatcher(encoder, decoder, info.Mapping, helper, overwrite) </ins> patchBytes, err := patcher.patch(info.Object, modified, info.Source, info.Namespace, info.Name) if err != nil {

Discussion:
This issue tracks the implementation of the --overwrite flag in kubectl apply, per in .
Changed the title to address only the --overwrite flag, since deals with the --force flag.
progress on this issue is blocked waiting for to merge.
Change:
// Total number of available pods (ready for at least minReadySeconds) targeted by this statefulset. // This is a beta field and enabled/disabled by StatefulSetMinReadySeconds feature gate. <ins> // +optional </ins> AvailableReplicas int32 `json:"availableReplicas" protobuf:"varint,11,opt,name=availableReplicas"` }

Discussion:
Looking at the for , it defines as a required attribute. But looking at the of , it states . Should this in fact be a required attribute? I come about this from using , a python package that generates models from the swagger definitions and thus builds a that requires an attribute that is not enabled. That only truly required attributes be required in the swagger definition Reproduction is not applicable as this is an issue with a spec No response Appeared in 1.22 (I believe) and affects current versions. Does not affect 1.21 n/a No response No response No response No response
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
alpha: has that is planned for removal in beta. ( results in fields as non-required in the OpenAPI) beta: removes the this might be a question whether feature gate controlled fields must remain until the feature gate is removed (and how would validation work in that case). ~old feature gates graduations to beta enabled a feature by default.~ a topic related to ? but it does not apply to feature gates. /kind documentation /sig apps
cc (since you are the author)
new fields to existing types must always be marked as +optional, since clients are not required to specify them
please open a PR adding back the +optional tag, regenerate openapi, and open picks back to 1.23 and 1.22
Change:
channel <- podUpdate expectPodUpdate(t, ch, CreatePodUpdate(kubetypes.ADD, TestSource, CreateValidPod("foo", "new"))) <del> // add an invalid update podUpdate = CreatePodUpdate(kubetypes.UPDATE, TestSource, &v1.Pod{ObjectMeta: metav1.ObjectMeta{Name: "foo"}}) </del> <ins> // add an invalid update, pod with the same name podUpdate = CreatePodUpdate(kubetypes.ADD, TestSource, CreateValidPod("foo", "new")) </ins> channel <- podUpdate expectNoPodUpdate(t, ch) }

Discussion:
Which test(s) are flaking: TestInvalidPodFiltered Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool: failures are seen, look at the logs to see the details about the error: /sig node cc
/assign
It is a bit funny that if I change to the following(wait for 3 seconds until receive event from channel): The test would consistently fail. I am not sure what the invalid update means at , so I cannot think of an ideal fix. I would like to defer to the members from sig-node. /unassign
Isn't this asserting a negative? I don't think it can work, especially not without a wait or some way of forcing the config mux storage merger thingy to run. The multiple levels is kind of mindbending, really. I come to the same conclusion as Maybe the focus needs to be on the invalid update? I do not understand why it is invalid from the context. Tracing it backwards in time, v1.8 was the last time this passed. v1.9 changed what validation means, I think I have a solution. /assign
Thanks for going deep down the commit history and found out the problem !
Made if either of you wish to review, and confirm my understanding.
Change:
persister: persister, } <del> return cache.setClient(issuer, clientID, provider), nil </del> <ins> return cache.setClient(clusterAddress, issuer, clientID, provider), nil </ins> } type oidcAuthProvider struct {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: We using go-code kubectl cli package. We are a long running app serving to many different Kubernetes clusters. Each cluster has a different user credentials and bearer token to access it. But they all use the same issuer and clientid. The oidc cache is keyed off of these two only. So what happens is when we switch to another configuration it pulls in the oidc provider for the other cluster and that bearer token does not have authority to this other cluster. The cluster config has the correct info in it but the oidc provider ignores that and used the stale data. What you expected to happen: oidc provider would always use the appropriate current config context to access the cluster How to reproduce it (as minimally and precisely as possible): In same app instance create two cluster configs to two different clusters with same oidc issuer and clientid by DIFFERENT credentials. Where the credentials on one are not authorized for the other cluster. Try to get namespaces on each, one will work and the other won't. Anything else we need to know?: Environment: Kubernetes version (use ): latest go-code from as a package called from go application.Cloud provider or hardware configuration: IBM Kubernetes OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Change:
} else { if _, ok := err.(*core.FitError); ok { glog.V(4).Infof("Unable to schedule %v %v: no fit: %v; waiting", pod.Namespace, pod.Name, err) <ins> } else if errors.IsNotFound(err) { if errStatus, ok := err.(errors.APIStatus); ok && errStatus.Status().Details.Kind == "node" { nodeName := errStatus.Status().Details.Name // when node is not found, We do not remove the node right away. Trying again to get // the node and if the node is still not found, then remove it from the scheduler cache. _, err := factory.client.CoreV1().Nodes().Get(nodeName, metav1.GetOptions{}) if err != nil && errors.IsNotFound(err) { node := v1.Node{ObjectMeta: metav1.ObjectMeta{Name: nodeName}} factory.schedulerCache.RemoveNode(&node) // invalidate cached predicate for the node if factory.enableEquivalenceClassCache { factory.equivalencePodCache.InvalidateAllCachedPredicateItemOfNode(nodeName) } } } </ins> } else { glog.Errorf("Error scheduling %v %v: %v; retrying", pod.Namespace, pod.Name, err) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In case scheduler misses a node delete event, or cleaning the node from scheduler cache errors out, node will stay in scheduler cache forever and scheduler will try to schedule pods on it and keeps seeing an error similar to: E1123 00:00:00 7 ] Error scheduling namespace pod-1: node 'node-xyz' not found; retrying When scheduler sees these "not found" errors for a node, it should delete the node from its cache. In order to tolerate transient errors, it is better if it deletes the node when it keeps seeing this error multiple times and over some period of time. /sig scheduling
I can help fix it.
In all my Kubernetes controllers I back up watch handlers with a full scan every now and than to reconciliate as a safety net. I guess that would help with thess kind of errors as well. Thanks for looking into this.
Thanks for the suggestion. That sounds like a better approach. I think we should have periodic full scan to deal with similar scenarios. We should probably do it for all cached objects, not just nodes.
Sorry, I do not know that how we can do periodic full scan because seems has not function. and it consumes a lot of resources for doing periodic full scan also.
Okay, just removing the node from the cache - like you suggested - is then probably the most straightforward way to do it.
I also suspected that periodic resync would be prohibitively expensive, but I don't have any concrete numbers. If it is not acceptable, as said, we can stick to the first solution of removing the node when scheduler faces a "node not found" error. We should not remove the node right away. I'd suggest trying again to get the node and if the node is still not found, then remove it from the scheduler cache. Doing the same thing for Pods would be useful too, but that would be a separate PR.
Closing from merge of
Change:
return nil, fmt.Errorf("Error creating LB floatingip %+v: %v", floatIPOpts, err) } } <ins> status := &v1.LoadBalancerStatus{} </ins> if floatIP != nil { <del> status.Ingress = append(status.Ingress, v1.LoadBalancerIngress{IP: floatIP.FloatingIP}) </del> <ins> status.Ingress = []v1.LoadBalancerIngress{{IP: floatIP.FloatingIP}} } else { status.Ingress = []v1.LoadBalancerIngress{{IP: loadbalancer.VipAddress}} </ins> } if lbaas.opts.ManageSecurityGroups {

Discussion:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig openstack /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).
Change:
}, }, }, <ins> VendorExtensible: spec.VendorExtensible{ Extensions: spec.Extensions{ "x-kubernetes-map-type": "atomic", }, }, </ins> }, } }

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:
package customresource_test import ( <ins> "context" "fmt" </ins> "reflect" "strings" "testing"

Discussion:
What happened: Using a command such as: fails with the following error: This bug happens on each run and started occurring as of v1.15.0. With v1.14 or older, I don't have such problem, i.e. it works flawlessly. What you expected to happen: The command succeeds: How to reproduce it (as minimally and precisely as possible): Create a CRD that has the scale subresource and try to scale a CR using . Example of such CRD can be found . Anything else we need to know?: Regarding the bug, it seems that it started appearing as of . Before the PR, we always fetched the resource and it worked because it had the resource version, while now we are only fetching it in case preconditions are provided (preconditions are not provided by default/when using ). Here is the output of a command: If I manually craft the request that has the resource version (or use the flag), it works. Is it as expected that the Scale resource requires the resource version in order for update to succeed? Shouldn't it always pick the latest resource version in case it isn't provided? On that note, I also noticed that if you want to update a CR by crafting the request manually and using , you also need to specify the resource version or you will get the same error. I'm not sure if this is expected and related, but I'm writing it down as it might be related. As far as I know, this is not required for some native resources at all, but I'm not sure is this the case for CRDs. Environment: Kubernetes version (use ):
/sig api-machinery cc
/sub
could you try to see if it fix the problem?
I've created a test cluster based on and I can confirm that I'm able to scale CustomResources using as usual. I used an to test this, such as: Thanks a lot for your time spent fixing this!
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17? I see you move it to 1.17 so I just wanted to be sure.
I guess could be merged now?

It is in the review queue and should still make 1.17
a kind reminder that code freeze for this release is on November 14.
I wanted to circle back around on this. We are 4 days out from code freeze. If this is still good based on just note here. Judging from the looks of it we are still good
Yes this should merge early in the week
Code freeze is tomorrow, this still going to make it?
yes, is still planned