jiebi/CodeConvo huggingface dataset:
Change:
Each node waiting for bootstrapping creates 1 line per 2-3s in the logs when the requesting client doesn't have access. It should not be logging at v(0), these are all v(4) level. We should be reporting these appropriately. I don't want a 5k node cluster showing this.
I'd like to fix it

Discussion:
deps = [ "//pkg/controller:go_default_library", "//vendor/github.com/golang/glog:go_default_library", <ins> "//vendor/github.com/juju/ratelimit:go_default_library", </ins> "//vendor/k8s.io/api/certificates/v1beta1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/runtime:go_default_library",

} if len(tried) != 0 { <del> return fmt.Errorf("recognized csr %q as %v but subject access review was not approved", csr.Name, tried) </del> <ins> return certificates.IgnorableError("recognized csr %q as %v but subject access review was not approved", csr.Name, tried) </ins> } return nil

"k8s.io/kubernetes/pkg/controller" "github.com/golang/glog" <ins> "github.com/juju/ratelimit" </ins> ) type CertificateController struct {

cc := &CertificateController{ kubeClient: kubeClient, <del> queue:      workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "certificate"), handler:    handler, </del> <ins> queue: workqueue.NewNamedRateLimitingQueue(workqueue.NewMaxOfRateLimiter( workqueue.NewItemExponentialFailureRateLimiter(200*time.Millisecond, 1000*time.Second), // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item) &workqueue.BucketRateLimiter{Bucket: ratelimit.NewBucketWithRate(float64(10), int64(100))}, ), "certificate"), handler: handler, </ins> } // Manage the addition/update of certificate requests

if err := cc.syncFunc(cKey.(string)); err != nil { cc.queue.AddRateLimited(cKey) <del> utilruntime.HandleError(fmt.Errorf("Sync %v failed with : %v", cKey, err)) </del> <ins> if _, ignorable := err.(ignorableError); !ignorable { utilruntime.HandleError(fmt.Errorf("Sync %v failed with : %v", cKey, err)) } else { glog.V(4).Infof("Sync %v failed with : %v", cKey, err) } </ins> return true }

return cc.handler(csr) } <ins> // IgnorableError returns an error that we shouldn't handle (i.e. log) because // it's spammy and usually user error. Instead we will log these errors at a // higher log level. We still need to throw these errors to signal that the // sync should be retried. func IgnorableError(s string, args ...interface{}) ignorableError { return ignorableError(fmt.Sprintf(s, args...)) } type ignorableError string func (e ignorableError) Error() string { return string(e) } </ins>
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig cli What happened: I accidentally tried to apply an invalid v1.List with : kubectl responded by crashing with a panic: What you expected to happen: An error message to be printed, perhaps of the "invalid List item: []". How to reproduce it (as minimally and precisely as possible): See description. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): CentOS 7.4 (1708) Kernel (e.g. ): Linux staging-head-2 3.10.0-693.2.2.el7.x8664 SMP Tue Sep 12 22:26:13 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Custom scripts Others:
I would try to fix it.
Can you add --validate=true in command line, then have a try?
cc

Discussion:
} func (v *SchemaValidation) validateList(object interface{}) []error { <del> fields := object.(map[string]interface{}) if fields == nil { </del> <ins> fields, ok := object.(map[string]interface{}) if !ok || fields == nil { </ins> return []error{errors.New("invalid object to validate")} } allErrors := []error{} <ins> if _, ok := fields["items"].([]interface{}); !ok { return []error{errors.New("invalid object to validate")} } </ins> for _, item := range fields["items"].([]interface{}) { if gvk, errs := getObjectKind(item); errs != nil { allErrors = append(allErrors, errs...)

func getObjectKind(object interface{}) (schema.GroupVersionKind, []error) { var listErrors []error <del> fields := object.(map[string]interface{}) if fields == nil { </del> <ins> fields, ok := object.(map[string]interface{}) if !ok || fields == nil { </ins> listErrors = append(listErrors, errors.New("invalid object to validate")) return schema.GroupVersionKind{}, listErrors }
Change:
This is wrong, cluster scoped resources should never have a NAMESPACE column. We need to fix and add a test to ensure this doesn't regress.
The presence of the flag is what triggers this.
I would help fix it.
I mean to add a test after modification, but found that current test framework could not support the case: To cover the scene, we need a real NewHumanReadablePrinter in test case, to ensure the output format, and modify the related funcs in FakeFactory to support pass in param withNamespace. I feel this not like behavior of unit test to some extent. The loss may outweighs the gain to have such a big impact on the whole. What's your opinion
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details

Discussion:
# Post-condition: valid-pod doesn't exist kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' <ins> ### Verify flag all-namespaces is ignored for rootScoped resources # Pre-condition: node exists kube::test::get_object_assert nodes "{{range.items}}{{$id_field}}:{{end}}" '127.0.0.1:' # Command output_message=$(kubectl get nodes --all-namespaces 2>&1) # Post-condition: output with no NAMESPACE field kube::test::if_has_not_string "${output_message}" "NAMESPACE" </ins> set +o nounset set +o errexit }

############################ if kube::test::if_supports_resource "${pods}" ; then <del> record_command run_kubectl_all_namespace_tests </del> <ins> if kube::test::if_supports_resource "${nodes}" ; then record_command run_kubectl_all_namespace_tests fi </ins> fi ################

} info := infos[0] mapping := info.ResourceMapping() <del> printer, err := f.PrinterForMapping(cmd, false, nil, mapping, allNamespaces) </del> <ins> // no need to print namespace for root-scoped resources printWithNamespace := allNamespaces if mapping != nil && mapping.Scope.Name() == meta.RESTScopeNameRoot { printWithNamespace = false } printer, err := f.PrinterForMapping(cmd, false, nil, mapping, printWithNamespace) </ins> if err != nil { return err }

w.Flush() } <ins> printWithNamespace := allNamespaces if mapping != nil && mapping.Scope.Name() == meta.RESTScopeNameRoot { printWithNamespace = false } </ins> var outputOpts *printers.OutputOptions // if cmd does not specify output format and useOpenAPIPrintColumnFlagLabel flag is true, // then get the default output options for this mapping from OpenAPI schema.

outputOpts, _ = outputOptsForMappingFromOpenAPI(f, mapping) } <del> printer, err = f.PrinterForMapping(cmd, false, outputOpts, mapping, allNamespaces) </del> <ins> printer, err = f.PrinterForMapping(cmd, false, outputOpts, mapping, printWithNamespace) </ins> if err != nil { if !errs.Has(err.Error()) { errs.Insert(err.Error())
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubectl cluster-info displays proxy urls for cluster services If those services are using https, the referenced urls do not work (they try to proxy using http) What you expected to happen: Services with a port name of https or 443 should use the ‘https:<name:<port‘ form How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign /sig cli

Discussion:
"//vendor/k8s.io/apimachinery/pkg/util/json:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/jsonmergepatch:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/mergepatch:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/util/net:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/strategicpatch:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/validation:go_default_library",

"strconv" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> utilnet "k8s.io/apimachinery/pkg/util/net" </ins> "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/kubectl/cmd/templates" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util"

link += "http://" + ip + ":" + strconv.Itoa(int(port.Port)) + " " } } else { <ins> name := service.ObjectMeta.Name if len(service.Spec.Ports) > 0 { port := service.Spec.Ports[0] // guess if the scheme is https scheme := "" if port.Name == "https" || port.Port == 443 { scheme = "https" } // format is <scheme>:<service-name>:<service-port-name> name = utilnet.JoinSchemeNamePort(scheme, service.ObjectMeta.Name, port.Name) } </ins> if len(client.GroupVersion.Group) == 0 { <del> link = client.Host + "/api/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name + "/proxy" </del> <ins> link = client.Host + "/api/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + name + "/proxy" </ins> } else { <del> link = client.Host + "/api/" + client.GroupVersion.Group + "/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name + "/proxy" </del> <ins> link = client.Host + "/api/" + client.GroupVersion.Group + "/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + name + "/proxy" </ins> } }
Change:
<!-- 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: Use the above two files create one PV and PVC, then delete the PVC, the PV will become failed but not released. The busybox recycler never succeed for power. /sig storage What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind bug The solution is like image, we should enable end user can customize the recycle image. It will not only fail on power but also s390x, so we should make sure the recycle image can be customized. /cc any comments for the solution?
Dup of . This issue can be closed, since we've already got flags and for this.
Just search and , but found that they are only defined as flags and no one is using them, can you please help double check, am I missing anything?
Also the claiming that it does not support multi node cluster, this is not acceptable.
: please see Please try them out, if they do not work then we can see how to get those fixed (and avoid adding yet another config option)
Yes, since we may only got only one (maybe setup several for LB, but they can be considered identical), it is necessary for running on non-amd64 platorm to have the right busybox image, which is exactly trying to fix. I've reopened . , so the simplest way is just replacing to . And docker will help us choose the right os-arch busybox image. What's remaining that mentioned is whether we should adding a new flag to add registry url for such recycler pod image exclusively.
Thanks and I also found an example here We do not need the registry url as the pod template was customized by the end user and they can define where got the recycler images. The problem is that the customized recycler will not work in mixed environments as only one recycle pod can be specified in controller manager, so +1 to , we should make support multi arch. not quite catch your idea of how to support, can you please provide some dummy yaml templates and some configuration files to explain? Thanks!
Actually all the , including , has been updated along with . This means will help us make the decision to choose the right busybox image. You can have a try to on different architectures, like and . A can help you and multi-arch docker images. With this support, on different os/arch can pull the right image with a same busybox image. As long as we have used such multi-arch images, those flags can work in a multi-node cluster.

Discussion:
Containers: []v1.Container{ { Name:    "pv-recycler", <del> Image:   "gcr.io/google_containers/busybox", </del> <ins> Image:   "busybox:latest", </ins> Command: []string{"/bin/sh"}, Args:    []string{"-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z "$(ls -A /scrub)" || exit 1"}, VolumeMounts: []v1.VolumeMount{
Change:
<!-- 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: Use the above two files create one PV and PVC, then delete the PVC, the PV will become failed but not released. The busybox recycler never succeed for power. /sig storage What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind bug The solution is like image, we should enable end user can customize the recycle image. It will not only fail on power but also s390x, so we should make sure the recycle image can be customized. /cc any comments for the solution?
Dup of . This issue can be closed, since we've already got flags and for this.
Just search and , but found that they are only defined as flags and no one is using them, can you please help double check, am I missing anything?
Also the claiming that it does not support multi node cluster, this is not acceptable.
: please see Please try them out, if they do not work then we can see how to get those fixed (and avoid adding yet another config option)
Yes, since we may only got only one (maybe setup several for LB, but they can be considered identical), it is necessary for running on non-amd64 platorm to have the right busybox image, which is exactly trying to fix. I've reopened . , so the simplest way is just replacing to . And docker will help us choose the right os-arch busybox image. What's remaining that mentioned is whether we should adding a new flag to add registry url for such recycler pod image exclusively.
Thanks and I also found an example here We do not need the registry url as the pod template was customized by the end user and they can define where got the recycler images. The problem is that the customized recycler will not work in mixed environments as only one recycle pod can be specified in controller manager, so +1 to , we should make support multi arch. not quite catch your idea of how to support, can you please provide some dummy yaml templates and some configuration files to explain? Thanks!
Actually all the , including , has been updated along with . This means will help us make the decision to choose the right busybox image. You can have a try to on different architectures, like and . A can help you and multi-arch docker images. With this support, on different os/arch can pull the right image with a same busybox image. As long as we have used such multi-arch images, those flags can work in a multi-node cluster.

Discussion:
Containers: []v1.Container{ { Name:    "pv-recycler", <del> Image:   "busybox:latest", </del> <ins> Image:   "busybox:1.27", </ins> Command: []string{"/bin/sh"}, Args:    []string{"-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z "$(ls -A /scrub)" || exit 1"}, VolumeMounts: []v1.VolumeMount{
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig network What happened: is adding logics to handle both the new () and deprecated () fields for making the transition easier. We should eventually get rid of such logics when CIs and most of the developers upgraded gcloud version to = 175.0.0. /assign
/area platform/gce
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
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 stale
/remove-lifecycle rotten

Discussion:
fi } <del> # TODO(#54017): Remove below logics for handling deprecated network mode field. # `x_gcloud_mode` was replaced by `x_gcloud_subnet_mode` in gcloud 175.0.0 and # the content changed as well. Keeping such logic to make the transition eaiser. </del> function check-network-mode() { local mode="$(gcloud compute networks list --filter="name=('${NETWORK}')" --project ${NETWORK_PROJECT} --format='value(x_gcloud_subnet_mode)' || true)" <del> if [[ -z "${mode}" ]]; then mode="$(gcloud compute networks list --filter="name=('${NETWORK}')" --project ${NETWORK_PROJECT} --format='value(x_gcloud_mode)' || true)" fi </del> # The deprecated field uses lower case. Convert to upper case for consistency. echo "$(echo $mode | tr [a-z] [A-Z])" }
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. Note that only can be assigned. <detailsIn response to : /assign 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
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)

Discussion:
// matches NodeInfo.node and the pod is not found in the pods list. Otherwise, // returns true. func (n *NodeInfo) Filter(pod *v1.Pod) bool { <del> pFullName := util.GetPodFullName(pod) </del> if pod.Spec.NodeName != n.node.Name { return true } for _, p := range n.pods { <del> if util.GetPodFullName(p) == pFullName { </del> <ins> if p.Name == pod.Name && p.Namespace == pod.Namespace { </ins> return true } }
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. Note that only can be assigned. <detailsIn response to : /assign 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
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)

Discussion:
func (cache *schedulerCache) FilteredList(podFilter PodFilter, selector labels.Selector) ([]*v1.Pod, error) { cache.mu.Lock() defer cache.mu.Unlock() <del> var pods []*v1.Pod </del> <ins> // podFilter is expected to return true for most or all of the pods. We // can avoid expensive array growth without wasting too much memory by // pre-allocating capacity. maxSize := 0 for _, info := range cache.nodes { maxSize += len(info.pods) } pods := make([]*v1.Pod, 0, maxSize) </ins> for _, info := range cache.nodes { for _, pod := range info.pods { if podFilter(pod) && selector.Matches(labels.Set(pod.Labels)) {