jiebi/CodeConvo huggingface dataset:
Code change:
UpdateNodeLabel       // 1000 UpdateNodeTaint       // 10000 UpdateNodeCondition   // 100000 <ins> UpdateNodeAnnotation  // 1000000 </ins> <del> All ActionType = 1<<iota - 1 // 111111 </del> <ins> All ActionType = 1<<iota - 1 // 1111111 </ins> // Use the general Update type if you don't either know or care the specific sub-Update type to use. <del> Update = UpdateNodeAllocatable | UpdateNodeLabel | UpdateNodeTaint | UpdateNodeCondition </del> <ins> Update = UpdateNodeAllocatable | UpdateNodeLabel | UpdateNodeTaint | UpdateNodeCondition | UpdateNodeAnnotation </ins> ) // GVK is short for group/version/kind, which can uniquely represent a particular API resource.

Related discussion:
text: Let me summarize each: Born from from is right. But, that's the problem with preCheck. (Some preCheck depends on some in-tree plugins' logic and it affects badly to other plugins enqueueing ) The preCheck is removed after is completed. After preCheck is removed, will be the correct behavior. So, we can do the optimization that changes node to a specific event. will be fixed in: It's kind of rare case, but I feel we need to have some improvement like Edit: create another issue for this: I'd say (2) and (3) are kind of rare cases. So, the blocker here is (1). (And, (1) is blocked by the removal of preCheck, which is blocked by ) As my conclusion, it's safer to add after (1) is done so that we can make sure the performance won't be affected badly. what do you think?
Instead, can we just keep an event for "node updated", then individual plugins can decide whether a annotations change is worth requeuing or not?
Yes, (1) can be replaced with that idea. But, I'd say changing to a specific is slightly better because the scheduling queue could filter out some Node update events without executing the hint functions.
If rescheduling can be triggered with precise events, that would be great. I haven't revisit since last time, I'll take a look again.
Since we are missing an event for , can we add it? But we also have to modify existing events like so: Because change of such field is also an Update. And in future releases we can get rid of some fine-grained events.
Since we will add hintFuncs for all in-tree plugins, so I think it's ok to add nodeAnnotationsChanged event now, we can filter out unrelated events in hitFuncs. Any other concerns? cc Prefer to keep them as people can register fine-gained events instead a general event.
If by "now" you mean v1.30, then I'm ok with that.
Code change:
gvk := schema.GroupVersionKind{ Group:   gv.Group, Version: gv.Version, <del> Kind:    gvks[0].Kind, </del> <ins> Kind:    gvk.Kind, </ins> } exampleOfGVK, err := scheme.New(gvk)

Related discussion:
text: I have an extension apiserver, and I was trying to upgrading the dependency . In our code, we have a serval resources has its , and we expect the storage version is their . for example, we have a resource in both and group, and they are wired up by method, and expected encoded as to storage. However, this seems broken after upgrade to v1.31, so I did some invertgation by myself, and I find the storage version is changed by here: In old behavior honor , but now don't. storage version semantic of would be honored. there is not easy approach, need to create an extension api server and find out. No response <detailsClient Version: v1.30.1 Kustomize Version: v5.0.4-0.- Server Version: v1.31.0-beta.0.25+-dirty </details<detailsNONE </details<detailsKind Cluster run on Darwin Darwin ReficuldeMacBook- 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:34 PDT 2023; root:xnu-.1.13~1/RELEASEARM64_T8103 arm64 </details<detailskind </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
/sig api-machinery
PTAL cc
Code change:
if exists && info.isActive() && info.portalPort == service.Spec.Port && info.portalIP.Equal(serviceIP) { continue } <del> if exists && (info.portalPort != service.Spec.Port || !info.portalIP.Equal(serviceIP) || service.Spec.CreateExternalLoadBalancer != (len(info.publicIP) > 0)) { </del> <ins> if exists && (info.portalPort != service.Spec.Port || !info.portalIP.Equal(serviceIP) || !ipsEqual(service.Spec.PublicIPs, info.publicIP)) { </ins> glog.V(4).Infof("Something changed for service %q: stopping it", service.Name) err := proxier.closePortal(service.Name, info) if err != nil {

Related discussion:
text: I'm not sure if it's the intended behaviour, but when I specify publicIPs for a service, external portals are only opened if createExternalLoadBalancer is set, too (this is checked in the OnUpdate function in ). After reading the docs, I would have expected that IPTables rules for external IPs are independent of the createExternalLoadBalancer flag. Also, we're running kubernetes locally, so setting createExternalLoadBalancer doesn't work since there's no cloud provider specified.
I was about to say it should work, but then I went and re-read the code and found at least one bug. Let me dig a bit more
You're right - the IPs actually propagate to the proxy, but it ignores them if createExternal... is not set. I think it is kosher to just do it. I'm prepping a PR
PR is up - if you feel bold you could test it in your environment...
Thanks, it's working fine with your patch.
Code change:
kube::test::get_object_assert 'pods --namespace=other' "{{range.items}}{{$id_field}}:{{end}}" 'valid-pod:' # Post-condition: verify shorthand `-n other` has the same results as `--namespace=other` kube::test::get_object_assert 'pods -n other' "{{range.items}}{{$id_field}}:{{end}}" 'valid-pod:' <ins> # Post-condition: a resource cannot be retrieved by name across all namespaces output_message=$(! kubectl get "${kube_flags[@]}" pod valid-pod --all-namespaces 2>&1) kube::test::if_has_string "${output_message}" "a resource cannot be retrieved by name across all namespaces" </ins> ### Delete POD valid-pod in specific namespace # Pre-condition: valid-pod POD exists

Related discussion:
text: The desciption of --all-namespaces is listing the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace." But when I used the following command: error: namespace may not be empty when retrieving a resource by name no namespace set on resource pods "counter" The error messages are unclear, and the second message isn't labeled as an error even.
And why couldn't use --all-namespaces flag?
You're asking for a specific pod name (counter) in all namespaces, which is a nonsensical query. The pod name is not a grep-like filter, it's a specific name. Yeah, the errors could be better. Describe could work, but potentially generates a LOT of information and API calls.
But I found the following API is supported now. Get The result is: has the more information. Do we need to support the following kubectl command(using the above API) or just return clear error messages? get pods counter --all-namespaces
I'd be ok with this being implemented via the field selector.
The issue is still here :). What's our expected result? I'd like to contribute this.
, after check the code, the URL was built by ; do you mean we should update it; or avoid to use , instead, build url () directly.
After checking the code, it's better to add fieldSelector to , is created for fieldSelector. Will submit a PR based on .
getting an object with a particular name across all namespaces seems like something we shouldn't encourage... it breaks the assumption of namespace independence.
, so we'll only update message for this issue? for example:
Disagree. Need easy way to troubleshouting the problem "why pods is stuck in Pending status". It's tiring for every pod to find who created it and in which namespace. In the logs there is only the name of the pod.
Now, with field selectors we can do To further my understanding, I'd ask:- doesn't itself break independence? One can search by label across all namespaces, it feels funny for by name to be special.
Code change:
func validateSecretKeySelector(s *api.SecretKeySelector, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{} <del> if len(s.Name) == 0 { allErrs = append(allErrs, field.Required(fldPath.Child("name"), "")) </del> <ins> nameFn := ValidateNameFunc(ValidateSecretName) for _, msg := range nameFn(s.Name, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("name"), s.Name, msg)) </ins> } if len(s.Key) == 0 { allErrs = append(allErrs, field.Required(fldPath.Child("key"), ""))

Related discussion:
text: Scenario: Expected results: pod would not be created as [0] is invalid Actual results: pod is created. Turns out we are not doing any validation of envFrom in container spec today.
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 .
I don't know that we can tighten without failing pods.
The validation code exists, but there was no wiring done from validateContainers.
Pods fail on kubelet already. So those pods were not doing much already. We had a BZ on this.
Fail how - fail to even start, or fail to get the input?