jiebi/CodeConvo huggingface dataset:
Change:
t := reflect.TypeOf(obj).Elem() gvk := version.WithKind(t.Name()) s.unversionedTypes[t] = gvk <del> if _, ok := s.unversionedKinds[gvk.Kind]; ok { panic(fmt.Sprintf("%v has already been registered as unversioned kind %q - kind name must be unique", reflect.TypeOf(t), gvk.Kind)) </del> <ins> if old, ok := s.unversionedKinds[gvk.Kind]; ok && t != old { panic(fmt.Sprintf("%v.%v has already been registered as unversioned kind %q - kind name must be unique", old.PkgPath(), old.Name(), gvk)) </ins> } s.unversionedKinds[gvk.Kind] = t }

Discussion:
We have moved to non-global schema in a number of places in 1.6 and 1.7. It is easy to forget registering the unversioned types like , leading to encoding errors in error cases. The registration of the unversioned types should be automatic as for the types, i.e. in .
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 and label list
do we need to close out this issue? (since referenced PR has merged)
Fixed by
Change:
if err != nil { return nil, fmt.Errorf("failed to decode managed fields: %v", err) } <del> // We can assume that patchObj is already on the proper version: // it shouldn't have to be converted so that it's not defaulted. // TODO (jennybuckley): Explicitly checkt that patchObj is in the proper version. </del> <ins> // Check that the patch object has the same version as the live object patchObj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal(patch, &patchObj.Object); err != nil { return nil, fmt.Errorf("error decoding YAML: %v", err) } if patchObj.GetAPIVersion() != f.groupVersion.String() { return nil, errors.NewBadRequest( fmt.Sprintf("Incorrect version specified in apply patch. "+ "Specified patch version: %s, expected: %s", patchObj.GetAPIVersion(), f.groupVersion.String())) } </ins> liveObjVersioned, err := f.toVersioned(liveObj) if err != nil { return nil, fmt.Errorf("failed to convert live object to proper version: %v", err)

Discussion:
What happened: When sending a request to the server side apply endpoint (), if the apiVersion provided in the object is different from the apiVersion in the url, it returns a 500 error, like: What you expected to happen: The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error. Anything else we need to know?: The check should probably be done somewhere near this . The issue, though, is that the patch is given as a byte array, and needs to be deserialized into an object to access the apiVersion field. How to reproduce it (as minimally and precisely as possible): With a kube-apiserver built from head, running with :
/kind bug /sig api-machinery /wg apply /priority important-longterm /assign
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/wait" clientset "k8s.io/client-go/kubernetes" <del> extensionsinternal "k8s.io/kubernetes/pkg/apis/extensions" </del> "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset" deploymentutil "k8s.io/kubernetes/pkg/controller/deployment/util" <del> "k8s.io/kubernetes/pkg/kubectl" </del> testutils "k8s.io/kubernetes/test/utils" )

Discussion:
As the title said, we need update touse server side reaper. xref:
/sig apps
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 and label list
/assign
Change:
apiVersion: extensions/v1beta1 kind: DaemonSet metadata: <del> name: fluentd-gcp-v1.34 </del> <ins> name: fluentd-gcp-v1.35 </ins> namespace: kube-system labels: k8s-app: fluentd-gcp kubernetes.io/cluster-service: "true" <del> version: v1.34 </del> <ins> version: v1.35 </ins> spec: template: metadata: labels: k8s-app: fluentd-gcp kubernetes.io/cluster-service: "true" <del> version: v1.34 </del> <ins> version: v1.35 </ins> spec: containers: - name: fluentd-gcp <del> image: gcr.io/google_containers/fluentd-gcp:1.34 </del> <ins> image: gcr.io/google_containers/fluentd-gcp:1.35 </ins> # If fluentd consumes its own logs, the following situation may happen: # fluentd fails to send a chunk to the server => writes it to the log => # tries to send this message to the server => fails to send a chunk and so on.

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): no What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): fluentd timezone timeformat Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): What happened: Log lines from docker have the wrong timestamp. Anything else do we need to know: We are building a custom Docker Image for fluentd/td-agent which is based on your Dockerfile but with some slight changes. One of which is that we set the timezone to something else than UTC. In this case fluentd will produce wrong timestamps for log lines since the string only includes a simple Z in the end. Changing the time_format to fixed the problem for us. Of course this is not really a bug in kubernetes but changing the default to the above will probably help others in the future.
Thanks for reporting! It seems to be a bug
Change:
echo "Generating protobuf requires protoc 3.0.0-beta1 or newer. Please download and" echo "install the platform appropriate Protobuf package for your OS: " echo <del> echo "  https://github.com/google/protobuf/releases" </del> <ins> echo "  https://github.com/protocolbuffers/protobuf/releases" </ins> echo echo "WARNING: Protobuf changes are not being validated" exit 1

Discussion:
google protobuf repository has moved from old location pointing currently to Point scripts to the new location ,kubernetes-csi/csi-lib-utils,kubernetes/kubernetes N/A Kubernetes version (use ): 1.21 Cloud provider or hardware configuration: N/A OS (e.g: ): Mac OS Kernel (e.g. ): Darwin Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
FYI
/assign
/area code-organization /kind cleanup
Change:
# $1: The name of the instance. # $2: The scopes flag. # $3: The minion start script. <del> function create-instance { </del> <ins> function create-minion { </ins> detect-project local attempt=0 while true; do

Discussion:
The node disk type should be an option in the cluster/gce/config-*.sh files. The nodes get created here:
And also the disk size.
How to do this for aws ? I am stuck at 10GB minion
It . A pull request adding it would be very welcome!
please check this thread
Hello there, can I do something to make this available in the command ? I'd like to us an SSD drive :)
Change:
// This returns the full identifier of the primary NIC for the given VM. func (ss *scaleSet) getPrimaryInterfaceID(machine compute.VirtualMachineScaleSetVM) (string, error) { <ins> if machine.NetworkProfile == nil || machine.NetworkProfile.NetworkInterfaces == nil { return "", fmt.Errorf("failed to find the network interfaces for vm %s", to.String(machine.Name)) } </ins> if len(*machine.NetworkProfile.NetworkInterfaces) == 1 { return *(*machine.NetworkProfile.NetworkInterfaces)[0].ID, nil } for _, ref := range *machine.NetworkProfile.NetworkInterfaces { <del> if *ref.Primary { </del> <ins> if to.Bool(ref.Primary) { </ins> return *ref.ID, nil } } <del> return "", fmt.Errorf("failed to find a primary nic for the vm. vmname=%q", *machine.Name) </del> <ins> return "", fmt.Errorf("failed to find a primary nic for the vm. vmname=%q", to.String(machine.Name)) </ins> } // getVmssMachineID returns the full identifier of a vmss virtual machine.

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: kube-controller-manager panic when network interfaces for Azure VMSS are null. This happens when Azure cloud provider tried to get IP address for VMSS VM: What you expected to happen: kube-controller-manager should report an error instead of panic. How to reproduce it (as minimally and precisely as possible): Scale cluster nodes up and down frequently. Anything else we need to know?: /kind bug /area provider/azure Environment: Kubernetes version (use ): 1.15+ Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /assign
Change:
fmt.Printf("--output wide is not available in kubectl config view; reset to default output format (%s)nn", defaultOutputFormat) cmd.Flags().Set("output", defaultOutputFormat) } <ins> if outputFormat == "" { fmt.Printf("reset to default output format (%s) as --output is empty", defaultOutputFormat) cmd.Flags().Set("output", defaultOutputFormat) } </ins> printer, _, err := cmdutil.PrinterForCommand(cmd) cmdutil.CheckErr(err)

Discussion:
The panic is bad but I would expect the command to return to me valid outputs I could use and error out. we should also make sure the nil dereference in the resource printer gets handled. Your PR justs masks it.
Btw, I didn't make up the empty string on purpose. It was documented in the output and it was seen as the default setting of . So perhaps someone should also fix the help text so newbies like me don't cause crashes as easily? Thanks.
I'd expect that we validate what's provided to and print the valid options if something unexpected was provided (including blank string). But the way we print flags that expect strings (and defaults to empty) in help can lead to this kind of confusion and other issues (on Windows, for example). A few ideas: pflag could have a "select" type that takes a list of valid options (and validates/throws errors automatically).
Agreed with that the current way of showing flags in the help is not optimal. cc:
I did agree that panic is bad, we should avoid this. The problem is if a user did use an empty output, how to handle this more properly. In PR you commented that we should not override user settings, it seems we should error out directly in this situation. Besides, nil dereference in the resource printer should be handled, will add this.
Change:
}, }, }) <ins> if apierrors.IsForbidden(err) { // The user is not allowed to create ClusterRoleBindings. This // probably means that RBAC is not being used. If RBAC is being // used, this test will probably fail later. framework.Logf("Attempt to create ClusterRoleBinding was forbidden: %v.", err) return } </ins> framework.ExpectNoError(err) err = framework.WaitForAuthorizationUpdate(f.ClientSet.Authorization(),

Discussion:
Three tests now create RoleBindings to give permissions to test service accounts: NodeProblemDetector Ingress PreStop Creating RBAC Rolebindings currently requires the user issuing the create call to have the required permissions. If RBAC is not enabled, and the cluster hasn't been configured with any RBAC bootstrapping, that won't be possible. We should make this test code conditional on whether RBAC is in use.
c.f.
Quick fix is to tolerate forbidden errors there and assume e2e setups using methods other than RBAC have already granted permissions to the service accounts
I'll put together a PR to tolerate the 403 in the test helper.
I think this can be closed now that the e2e RBAC setup is best effort and failures there don't affect the test if another authorizer is in use
I agree. My original thought was that we'd make the RBAC test stuff only happen on RBAC-enabled setups. But, since we're going to be pushing setups towards using RBAC, we might as well have those pieces stick around in the common code (as best-effort).
Change:
return ErrWaitTimeout } case <-done: <del> closeCh() </del> <ins> return ErrWaitTimeout </ins> } } <del> return ErrWaitTimeout </del> } // poller returns a WaitFunc that will send to the channel every interval until

Discussion:
Users of the function would expect the close of the "done" channel should terminate the . We should change the function to align to users' expectation. We should document what the channel does. This is a behavior change, to be cautious, we should add a release note claiming breaking change. /kind bug
/sig api-machinery cc Feel free to assign to yourself if you have time. Otherwise I'll attempt a fix tomorrow ;)
I'll fix it. /assign
GitHub didn't allow me to assign the following users: kdada. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : I'll fix it. 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
/cc
Change:
if podErr != nil { // Pod failed. Dump all logs from all containers to see what's wrong <del> _ = apiv1pod.VisitContainers(&podStatus.Spec, apiv1pod.AllFeatureEnabledContainers(), func(c *v1.Container, containerType apiv1pod.ContainerType) bool { </del> <ins> _ = podutils.VisitContainers(&podStatus.Spec, podutils.AllContainers, func(c *v1.Container, containerType podutils.ContainerType) bool { </ins> logs, err := e2epod.GetPodLogs(ctx, f.ClientSet, ns, podStatus.Name, c.Name) if err != nil { framework.Logf("Failed to get logs from node %q pod %q container %q: %v",

Discussion:
Several test/e2e/framework/* packages have as their only dependency on k/k. The following functions are shared that way: IsPodAvailable returns true if a pod is available; false otherwise. IsPodReady returns true if a pod is ready; false otherwise. VisitContainers invokes the visitor function with a pointer to every container spec in the given pod spec with type set in mask. If visitor returns false, visiting is short-circuited. VisitContainers returns true if visiting completes, false if visiting was short-circuited. AllFeatureEnabledContainers returns a ContainerType mask which includes all container types except for the ones guarded by feature gate. The feature gate check in AllFeatureEnabledContainers is problematic. E2E tests don't know what the feature gates in the cluster are. The rest of the functions look like something that could be moved into == Having the functions in makes it clearer that the checks only depend on aspects of the public API. Reduces dependencies of e2e/framework on k/k, in case that we want to move it into staging. Prevents accidentally using checks that only work in-tree (like feature gates).
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 testing
/assign
Change:
return fmt.Errorf("unsupported CRI runtime: %q, only %q is currently supported", f.ContainerRuntime, kubetypes.RemoteContainerRuntime) } <ins> // Note: maybe we can test it for being a valid socket address as an additional improvement. // The only problem with it will be that some setups may not specify 'unix://' prefix. // So just check empty for back compat. if f.RemoteRuntimeEndpoint == "" { return fmt.Errorf("the container runtime endpoint address was not specified or empty, use --container-runtime-endpoint to set") } </ins> return nil }

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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 node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
// WaitFor continually checks 'fn' as driven by 'wait'. // // WaitFor gets a channel from 'wait()'', and then invokes 'fn' once for every value <del> // placed on the channel and once more when the channel is closed. </del> <ins> // placed on the channel and once more when the channel is closed. If the channel is closed // and 'fn' returns false without error, WaitFor returns ErrWaitTimeout. </ins> // <del> // If 'fn' returns an error the loop ends and that error is returned, and if </del> <ins> // If 'fn' returns an error the loop ends and that error is returned. If </ins> // 'fn' returns true the loop ends and nil is returned. // <del> // ErrWaitTimeout will be returned if the channel is closed without fn ever </del> <ins> // ErrWaitTimeout will be returned if the 'done' channel is closed without fn ever </ins> // returning true. <ins> // // When the done channel is closed, because the golang `select` statement is // "uniform pseudo-random", the `fn` might still run one or multiple time, // though eventually `WaitFor` will return. </ins> func WaitFor(wait WaitFunc, fn ConditionFunc, done <-chan struct{}) error { stopCh := make(chan struct{}) <del> once := sync.Once{} closeCh := func() { once.Do(func() { close(stopCh) }) } defer closeCh() </del> <ins> defer close(stopCh) </ins> c := wait(stopCh) for { select {

Discussion:
Users of the function would expect the close of the "done" channel should terminate the . We should change the function to align to users' expectation. We should document what the channel does. This is a behavior change, to be cautious, we should add a release note claiming breaking change. /kind bug
/sig api-machinery cc Feel free to assign to yourself if you have time. Otherwise I'll attempt a fix tomorrow ;)
I'll fix it. /assign
GitHub didn't allow me to assign the following users: kdada. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : I'll fix it. 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
/cc
Change:
"gce_healthchecks_test.go", "gce_loadbalancer_external_test.go", "gce_test.go", <ins> "gce_util_test.go", </ins> "metrics_test.go", ], importpath = "k8s.io/kubernetes/pkg/cloudprovider/providers/gce",

Discussion:
/kind bug What happened: Continuation of . The fix to that bug only takes the first subnetwork in the correct region. However, if the user manual subnets in the region that the cluster exists, it's possible the cloudprovider could choose the wrong subnet. What you expected to happen: If no subnet is specified for a non-legacy network, always take the subnet which was automatically created. /assign /sig network /area platform/gce
Change:
return replicas, metric, statuses, timestamp, nil } <del> func (a *HorizontalController) reconcileKey(key string) error { </del> <ins> func (a *HorizontalController) reconcileKey(key string) (deleted bool, err error) { </ins> namespace, name, err := cache.SplitMetaNamespaceKey(key) if err != nil { <del> return err </del> <ins> return true, err </ins> } hpa, err := a.hpaLister.HorizontalPodAutoscalers(namespace).Get(name) if errors.IsNotFound(err) { klog.Infof("Horizontal Pod Autoscaler %s has been deleted in %s", name, namespace) delete(a.recommendations, key) <del> return nil </del> <ins> return true, nil </ins> } <del> return a.reconcileAutoscaler(hpa, key) </del> <ins> return false, a.reconcileAutoscaler(hpa, key) </ins> } // computeStatusForObjectMetric computes the desired number of replicas for the specified metric of type ObjectMetricSourceType.

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!--What happened: Resync period for HorizontalPodAutoscaler controller is set to 15 seconds in order to update HPAs every 15 seconds. Sometimes updates are skipped and period between two updates is 30 seconds. What you expected to happen: HPA should be updated every 15 seconds. How to reproduce it (as minimally and precisely as possible): Add debugs to HPA controller showing how often HPAs are processed. Create HPA. Anything else we need to know?: HPA controller uses rate RateLimitingQueue: New requests are always with 15 seconds delay: If request for the given HPA is in the queue then newly request is skipped. Requests are and removed from the queue at the same moment so there is a race condition. See following scenario: 00:00:00 - Resync adds request to queue to be executed at 00:00:15 00:00:15 - Resync adds next request to queue to be executed at 00:00:30 but it is skipped because previous request is still in the queue 00:00:15 - Request at 00:00:00 is executed 00:00:30 - Resync adds next request to queue to be executed at 00:00:45 00:00:45 - Request at 00:00:30 is executed In above scenario HPA wasn't updated between 00:00:15 and 00:00:45. Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: GKE <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig autoscaling
/assign krzysztof-jastrzebski