jiebi/CodeConvo huggingface dataset:
Code change:
# # $1 - server architecture kube::build::get_docker_wrapped_binaries() { <del> local debian_iptables_version=buster-v1.4.0 </del> <ins> local debian_iptables_version=buster-v1.5.0 </ins> local go_runner_version=buster-v2.2.4 ### If you change any of these lists, please also update DOCKERIZED_BINARIES ### in build/BUILD. And kube::golang::server_image_targets

Related discussion:
text: The based container images for are shipped with the wrong architecture within the manifest if not amd64: Refers to We updated the images a few minutes ago to buster-v1.3.0, which are now ready to be used as base for the multi-architecture images. If the images contain the right architectures, then it may magically happen that the kube-proxy images are fixed, too. This is because we already use the build syntax for it: /cc
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 release
Code change:
function kube-up { <ins> echo "Starting cluster using os distro: ${KUBE_OS_DISTRIBUTION}" >&2 </ins> get-tokens detect-image

Related discussion:
text: Example: kubectl cluster-info shows a redundant line: The cluster is already up, so the phrase "Starting cluster" is confusing in context of the command. (My kubernetes test cluster is running on AWS i.e. KUBERNETES_PROVIDER=aws. I had used kube- to create a test kubernetes cluster on aws). Log of my shell session:
Thanks for the bug report I've filed a PR to fix it.
Code change:
if strings.Compare(p.Status.Conditions[0].Reason, "Unschedulable") != 0 { t.Fatalf("Failed as Pod %s reason was: %s but expected: Unschedulable", podName, p.Status.Conditions[0].Reason) } <del> if !strings.Contains(p.Status.Conditions[0].Message, "MatchNodeSelector") || !strings.Contains(p.Status.Conditions[0].Message, "VolumeNodeAffinityConflict") { t.Fatalf("Failed as Pod's %s failure message does not contain expected keywords: MatchNodeSelector, VolumeNodeAffinityConflict", podName) </del> <ins> if !strings.Contains(p.Status.Conditions[0].Message, "node(s) didn't match node selector") || !strings.Contains(p.Status.Conditions[0].Message, "node(s) had volume node affinity conflict") { t.Fatalf("Failed as Pod's %s failure message does not contain expected message: node(s) didn't match node selector, node(s) had volume node affinity conflict", podName) </ins> } if err := config.client.CoreV1().Pods(config.ns).Delete(podName, &metav1.DeleteOptions{}); err != nil { t.Fatalf("Failed to delete Pod %s: %v", podName, err)

Related discussion:
text: <!-- 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 feature The is not user friendly. There has been to make it better, but we still print in the pending message. We should change these errors to a more human readable message. For example, should be changed to something like . /sig scheduling
Code change:
} delete(plugin.podCIDRs, id) <ins> glog.V(3).Infof("Calling cni plugins to remove container from network with cni runtime: %+v", rt) </ins> if err := plugin.cniConfig.DelNetwork(plugin.netConfig, rt); err != nil { return fmt.Errorf("Error removing container from network: %v", err) }

Related discussion:
text: Event for a pod: The cni plugins do exist at /opt/cni/bin. They cannot be executed and bash is complaining:
cc
I'm guessing this is a shared lib problem, since /usr/grte/v4/lib64/ld-linux-x86- doesn't exist on my gce vm. We should update docs to make it clear how someone would install manually (if they run into such problems again) and statically link (if the problem is indeed the shared lib) with something like Unsure how we'd support different GOOS (vend different tarballs vs checking in and building the plugin inline with our make scripts)
uggh. These binaries need to be ultra-static or else we need to containerize them.
Essentially doing would've prevented this bug :)
And see for the CNI_ARGS problems
also , re ... however, I'm not too sure if your comment was mean to be on this ticket.
cc
I have a working version. I uploaded my cni binary with bug fix on GCS. change source to change sourcehash to Welcome to give it a try.
Also see problem:
Code change:
<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/horizontal-pod-autoscaling/README.md?pixel)]() <del> <!-- END MUNGE: GENERATED_ANALYTICS --> </del> <ins> <!-- END MUNGE: GENERATED_ANALYTICS --> </ins>  No newline at end of file

Related discussion:
text: The heapster needs to be installed if end user want to use autoscaler feature, we should mention this in document.
Code change:
return nil } <del> func (ctrl *controller) getParameters(ctx context.Context, claim *resourcev1alpha2.ResourceClaim, class *resourcev1alpha2.ResourceClass) (claimParameters, classParameters interface{}, err error) { </del> <ins> func (ctrl *controller) getParameters(ctx context.Context, claim *resourcev1alpha2.ResourceClaim, class *resourcev1alpha2.ResourceClass, notifyClaim bool) (claimParameters, classParameters interface{}, err error) { </ins> classParameters, err = ctrl.driver.GetClassParameters(ctx, class) if err != nil { <ins> ctrl.eventRecorder.Event(class, v1.EventTypeWarning, "Failed", err.Error()) </ins> err = fmt.Errorf("class parameters %s: %v", class.ParametersRef, err) return } claimParameters, err = ctrl.driver.GetClaimParameters(ctx, claim, class, classParameters) if err != nil { <ins> if notifyClaim { ctrl.eventRecorder.Event(claim, v1.EventTypeWarning, "Failed", err.Error()) } </ins> err = fmt.Errorf("claim parameters %s: %v", claim.Spec.ParametersRef, err) return }

Related discussion:
text: When ResourceClaimParameters or ResourceClassParameters fail validation in resource driver during PodSchedulingContext sync loop, the error is visible only in the events of the PodSchedulingContext. The error should be visible on the object that fails validation as well, ResourceClaim or ResourceClass respectively. Creating ResourceClaim with unsupported parameters' values or unsupported No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig node
/triage accepted
KEP:
Code change:
}, } <del> resolvConf, cleanup := getResolvConf(t) defer cleanup() </del> <ins> resolvConfContent := []byte(fmt.Sprintf("nameserver %snsearch %sn", testHostNameserver, testHostDomain)) tmpfile, err := os.CreateTemp("", "tmpResolvConf") if err != nil { t.Fatal(err) } defer os.Remove(tmpfile.Name()) if _, err := tmpfile.Write(resolvConfContent); err != nil { t.Fatal(err) } if err := tmpfile.Close(); err != nil { t.Fatal(err) } </ins> <del> configurer := NewConfigurer(recorder, nodeRef, nil, []net.IP{netutils.ParseIPSloppy(testClusterNameserver)}, testClusterDNSDomain, resolvConf) configurer.getHostDNSConfig = fakeGetHostDNSConfigCustom </del> <ins> configurer := NewConfigurer(recorder, nodeRef, nil, []net.IP{netutils.ParseIPSloppy(testClusterNameserver)}, testClusterDNSDomain, tmpfile.Name()) </ins> testCases := []struct { desc              string

Related discussion:
text: When a --resolv-conf (DNS resolver config) is passed to kubelet on a Windows node, the config content is used as part of sandbox initialization (through getHostDNSConfig()). Now with the recent changes (), it seems now to fail with an error like: E0315 10:22:16. 4764 ] "Error syncing pod, skipping" err="failed to "CreatePodSandbox" for "img-pull-(-b40a-459d-9033-)" with CreatePodSandboxError: "Failed to generate sandbox config for pod "img-pull-(-b40a-459d-9033-)": Unexpected resolver config value: "C:etckubernetescni". Expected "" or "Host"."" pod="img-puller-3842/img-pull-" podUID=-b40a-459d-9033- This is showing on all the runs of GCE testgrid (latest): Reading/using the passed resolv config on Windows Run a Windows pool with DNS resolv config being set as part of kubelet params. No response_ 27 alpha.3 1.27 beta.0 master <detailsGCE </details<details</details<details</details<details</details<details</details
/triage accepted /milestone v1.27 /sig node /sig network
/sig windows /cc
/priority criticial-urgent as this is likely a release blocking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority criticial-urgent 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
/priority critical-urgent
Hmm, so you're setting the [1]. This PR introduced the capability to read the DNS config options from the Windows host registries while removing the capability to read from a file, introducing a regression. I've sent a PR addressing this issue: [1]
Is the file you are pointing to a UNIX-style or something else?
Was the file changing the behavior of the node?
Code change:
}, } <del> resolvConf, cleanup := getResolvConf(t) defer cleanup() </del> <ins> resolvConfContent := []byte(fmt.Sprintf("nameserver %snsearch %sn", testHostNameserver, testHostDomain)) tmpfile, err := os.CreateTemp("", "tmpResolvConf") if err != nil { t.Fatal(err) } defer os.Remove(tmpfile.Name()) if _, err := tmpfile.Write(resolvConfContent); err != nil { t.Fatal(err) } if err := tmpfile.Close(); err != nil { t.Fatal(err) } </ins> <del> configurer := NewConfigurer(recorder, nodeRef, nil, []net.IP{netutils.ParseIPSloppy(testClusterNameserver)}, testClusterDNSDomain, resolvConf) configurer.getHostDNSConfig = fakeGetHostDNSConfigCustom </del> <ins> configurer := NewConfigurer(recorder, nodeRef, nil, []net.IP{netutils.ParseIPSloppy(testClusterNameserver)}, testClusterDNSDomain, tmpfile.Name()) </ins> testCases := []struct { desc              string

Related discussion:
text: Yeah, what used on GCE/GKE, seems to be a Linux-like conf, eg: nameserver 10.128.0.1 search c.<project_name.internal google.internal ` We haven't tried to remove from kubelet to see the behavior.
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
I opened up a revert PR in case this PR does not merge by code freeze.
Thanks for the resolution! both 2019 and 2022 grids seems to be back to green now!
Thanks for confirming! I opened to ensure gets updated too
Code change:
useCustomImsCache: true, expectedErrMsg:    fmt.Errorf("getError"), }, <del> { name:           "NodeAddresses should report error if VMSS instanceID is invalid", nodeName:       "vm123456", metadataName:   "vmss_$123", providerID:     "azure:///subscriptions/subscription/resourceGroups/rg/providers/Microsoft.Compute/virtualMachines/vm1", vmType:         vmTypeVMSS, expectedErrMsg: fmt.Errorf("failed to parse VMSS instanceID %q: strconv.ParseInt: parsing %q: invalid syntax", "$123", "$123"), }, </del> } for _, test := range testcases {

Related discussion:
text: <!-- 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: If computer name prefix does not match VMSS name, then Azure cloud provider will use VMSS API instead of using metadata service data. This leads to throttling, because every affected kubelet is making API requests. What you expected to happen: Azure cloud provider should use metadata service data instead of calling VMSS API when instance is current. How to reproduce it (as minimally and precisely as possible): Set computer name prefix of the VMSS to something different than default. You should observe Azure provider making requests to the VMSS API rather than using metadata service, which leads to throttling if you have multiple kubelets with this bug. Anything else we need to know?: This is bug was introduced by - returns false even if instance is current, because it expects node name to match VMSS name + instance id, however node name is derived from the computer-name-prefix which can be different than VMSS name. Node name should be matched against , not against . Environment: Kubernetes version (use ): 1.18.x and higher Cloud provider or hardware configuration: azure /sig cloud-provider
/sig cloud-provider
/area provider/azure
CC
/remove-sig cloud-provider /sig cloud-provider (trying to remove the label)
/sig cloud-provider
Thanks for the reporting. Unfortunately, computer name prefix is not included in IMDS, so it can't be used without VMSS API for constructing the NodeName. Would check what could we do to workaround the issue.
Can you memorize the computer name prefix in the first request to the Azure API and then use it for the isCurrentInstance check?
opened to fix the issue. Would you like to have a look?
I can confirm that your change should fix the problem I reported. Do you know if your fix will be to 1.18.x?
is working on the cherry pick
Thank you for quick fix!
Code change:
// +listType=map // +listMapKey=name // +optional <del> Variables []Variable `json:"variables" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,7,rep,name=variables"` </del> <ins> Variables []Variable `json:"variables,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,7,rep,name=variables"` </ins> } // ParamKind is a tuple of Group Kind and Version.

Related discussion:
text: spec.variables should be marked omitempty. I'm trying to create a validating admission policy that uses in v1.27 as follows: I'm setting : to "Strict" in CreateOptions so that the server will reject requests with unknown fields but it complains that the don't exist in v1.27 and it does make sense because this field was introduced in v1.28: I'm using a 1.28 client.
/sig api-machinery
/assign
/assign /triage accepted
Thanks for raising this! /cc
Code change:
return len(br) } <ins> // Less breaks ties first by creation timestamp, then by name </ins> func (br byRevision) Less(i, j int) bool { <ins> if br[i].Revision == br[j].Revision { if br[j].CreationTimestamp.Equal(&br[i].CreationTimestamp) { return br[i].Name < br[j].Name } return br[j].CreationTimestamp.After(br[i].CreationTimestamp.Time) } </ins> return br[i].Revision < br[j].Revision }

Related discussion:
text: <!-- 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: Statefulsets are sometimes continually rolling pods and I don't know why statefulset created: storageclass referenced: kubectl describe statefulset statefulset-test: As you can see from the above describe, the pod in the statefulset has been restarted a lot of times. Observing the created pod, 1) The pod comes up ready 2) immediately transitions to terminating 3) Is terminated 4) A new pod is created 5) Go back to (1) (repeats forever) Despite no updates to the statefulset spec ocurring. Making a change to the statefulset template (for example a trivial change adding a nonsense annotation) stops the rolling and fixes the issue When this statefulset was created, there was a mutating webhook enabled. After the observed pod rolling. I disabled this by making its configuration invalid and making it non required, and the rolling persisted. The status of the statefulset: : You can see that there is a discrepency between currentRevision and updateRevision. currentRevision: statefulset-test- updateRevision: statefulset-test- A short while later the status is changed to contain currentRevision: statefulset-test- updateRevision: statefulset-test- This change happened at Sun Apr 1 19:48:48 2018 Presumably after the rollout of statefulset-test- is complete.
Code change:
return len(br) } <ins> // Less breaks ties first by creation timestamp, then by name </ins> func (br byRevision) Less(i, j int) bool { <ins> if br[i].Revision == br[j].Revision { if br[j].CreationTimestamp.Equal(&br[i].CreationTimestamp) { return br[i].Name < br[j].Name } return br[j].CreationTimestamp.After(br[i].CreationTimestamp.Time) } </ins> return br[i].Revision < br[j].Revision }

Related discussion:
text: Here are all the controllerrevisions from above: kubectl get controllerrevision statefulset-test- -o yaml kubectl get controllerrevision statefulset-test- -o yaml: kubectl get controllerrevision statefulset-test- -o yaml: The differences between the above controllerrevisions are insignificant (the hash, the creation timestamp, the name, the resource version, the uid, the self link) Interestingly all these controllerrevisions were created very close together in time shortly after I created the statefulset The current controllerrevisions are After watching the state change for a while, it actually seems like the statefulset is just cycling through the updateRevision being one of the above 10 controllerrevisions Leaders during this time From kube-controller-manager logs during this time, here is one excerpt: The error sync in there is suspicous, and as you can see the controllerrevisions are changing in the logs I have the full logs from a 5 minute window on either side of the above if necessary. The reason I'm inclined to think this is a kubernetes bug is that any update to the statefulset template fixes the problem. How to reproduce it (as minimally and precisely as possible): Not really sure. Worth just trying to create the above statefulset (requires creating the I tried deleting and recreating the above statefulset and it didn't happen, so something flaky is going on Anything else we need to know?: kubernetes 1.9.3 (client and server) cloud provider: aws
/sig apps
I realize this will probably need some further debugging, happy to get some direction
Consistent repro: Create a statefulset that creates a controllerrevision whose hash is between max int32 and max uint32 (this shouldn't be that hard to do, possibly a 50/50 chance of this). Manually create a controllerrevision identical to the first (same revision), incrementing both the name and hash by one. See that the statefulset controller will continually switch which controller revision should be the target of the statefulset.
Due to the issue fixed here: , under some circumstances controllerrevisions whose revision is the same were being considered equal.
Code change:
return len(br) } <ins> // Less breaks ties first by creation timestamp, then by name </ins> func (br byRevision) Less(i, j int) bool { <ins> if br[i].Revision == br[j].Revision { if br[j].CreationTimestamp.Equal(&br[i].CreationTimestamp) { return br[i].Name < br[j].Name } return br[j].CreationTimestamp.After(br[i].CreationTimestamp.Time) } </ins> return br[i].Revision < br[j].Revision }

Related discussion:
text: This ends up causing this bug to manifest as follows: ListRevisions finds many controllerrevisions with the same revision (unclear how this state happens, but it can happen) The sort here randomly sorts them Due to the linked bug , FindEqualRevisions incorrectly finds that all these controller revisions are equal to the proposed udpate. The updateRevision selects the last revision found here Therefore, updateRevision, is randomly selected and causes the bug. This fixes the immediate issue, but the sort should probably be made stable (i.e not just look at the revision number, perhaps just consider the hash for tie breakers)
As an update, fixing the equality check will not be sufficient because it is possible for multiple controller revisions to be created that are actually equal, including the same hash, that have the same revision number. I believe the fix will need to be equal controllerrevisions with the same revision number from being created sort the controllerrevisions so that the controllerrevision that is the target of the statefulset is stable
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
/remove-lifecycle stale
ping I use the K8S which version is 1.11.4 and encounter the same problem. I want to reproduce the problem and find your way: Manually create a controllerrevision identical to the first (same revision), incrementing both the name and hash by one. Could you tell me how to mannually create a same controllerrevision identical to the first? Thanks in anvance.
Code change:
<ins> DOCKER_OPTS="" </ins> {% if grains.docker_opts is defined %} <del> {% set docker_opts = grains.docker_opts %} {% else %} {% set docker_opts = "" %} </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} {{grains.docker_opts}}" </ins> {% endif %} <del> DOCKER_OPTS="{{docker_opts}} --bridge cbr0 --iptables=false --ip-masq=false -r=false" </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} --bridge cbr0 --iptables=false --ip-masq=false -r=false" </ins>

Related discussion:
text: 0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was
Code change:
# Downloaded kubernetes binary release tar ball kubernetes.tar.gz <del> # generated files in any directory # TODO(thockin): uncomment this when we stop committing the generated files. #zz_generated.* zz_generated.openapi.go </del> <ins> # Phony test files used as part of coverage generation </ins> zz_generated_*_test.go <del> # TODO(roycaihw): remove this when we stop committing the generated definition !staging/src/k8s.io/apiextensions-apiserver/pkg/generated/openapi/zz_generated.openapi.go !staging/src/k8s.io/kube-aggregator/pkg/generated/openapi/zz_generated.openapi.go # low-change blueprint in code-generator to notice changes !staging/src/k8s.io/code-generator/examples/apiserver/openapi/zz_generated.openapi.go # low-change sample-apiserver spec to be compilable when published !staging/src/k8s.io/sample-apiserver/pkg/generated/openapi/zz_generated.openapi.go </del> # make-related metadata /.make/

Related discussion:
text: Checked in: Not checked in: Can anyone explain why?
ones published outside k/k that are in libraries/modules expected to be usable without running custom code generation steps are checked in
example issue: there were similar issues with other instances
/triage accepted
I guess I am asking why not check in
oh, I'd be in favor of that :)
downstream users very often end up realizing that we warn folks not to use ( ) because they go looking for why this file is not checked in. This paper cut makes people realize that they are doing something that we don't want them to do. (not arguing for or against, just stating where this was effective before)
I think the v0.0.0 local replace directives in accomplish similar things w.r.t. making people go digging about friction using k/k as a library