jiebi/CodeConvo huggingface dataset:
Code change:
What would you like to be : Currently the apiserver has request latencies metrics, which are a histogram of requests to the apiserver. However, these request metrics do not include healthz. While we have recently the ability to get back health check metrics from the healthz endpoint directly, we should also emit this data as a metric, so that we can monitor health check latencies. /assign /sig api-machinery instrumentation
GitHub didn't allow me to assign the following users: jktomer. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : What would you like to be : /sig api-machinery instrumentation 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
I noticed this is informally assigned. Has there been any progress? Is this a place I can fit in?
Yes, I'm working on a PR.
/assign
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

Related discussion:
text: klog.V(5).Infof("Installing health checkers for (%v): %v", path, formatQuoted(checkerNames(checks...)...)) <del> mux.Handle(path, handleRootHealthz(checks...)) </del> <ins> mux.Handle(path, metrics.InstrumentHandlerFunc("GET", /* group = */ "", /* version = */ "", /* resource = */ "", /* subresource = */ path, /* scope = */ "", /* component = */ "", handleRootHealthz(checks...))) </ins> for _, check := range checks { mux.Handle(fmt.Sprintf("%s/%v", path, check.Name()), adaptCheckToHandler(check.Check)) }
Code change:
What would you like to be : Currently the apiserver has request latencies metrics, which are a histogram of requests to the apiserver. However, these request metrics do not include healthz. While we have recently the ability to get back health check metrics from the healthz endpoint directly, we should also emit this data as a metric, so that we can monitor health check latencies. /assign /sig api-machinery instrumentation
GitHub didn't allow me to assign the following users: jktomer. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : What would you like to be : /sig api-machinery instrumentation 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
I noticed this is informally assigned. Has there been any progress? Is this a place I can fit in?
Yes, I'm working on a PR.
/assign
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

Related discussion:
text: "net/http/httptest" "net/url" "reflect" <ins> "strings" </ins> "testing" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apiserver/pkg/endpoints/metrics" "k8s.io/component-base/metrics/legacyregistry" "k8s.io/component-base/metrics/testutil" </ins> ) func TestInstallHandler(t *testing.T) {
Code change:
What would you like to be : Currently the apiserver has request latencies metrics, which are a histogram of requests to the apiserver. However, these request metrics do not include healthz. While we have recently the ability to get back health check metrics from the healthz endpoint directly, we should also emit this data as a metric, so that we can monitor health check latencies. /assign /sig api-machinery instrumentation
GitHub didn't allow me to assign the following users: jktomer. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : What would you like to be : /sig api-machinery instrumentation 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
I noticed this is informally assigned. Has there been any progress? Is this a place I can fit in?
Yes, I'm working on a PR.
/assign
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

Related discussion:
text: } } <ins> func TestMetrics(t *testing.T) { mux := http.NewServeMux() InstallHandler(mux) InstallLivezHandler(mux) InstallReadyzHandler(mux) metrics.Register() metrics.Reset() paths := []string{"/healthz", "/livez", "/readyz"} for _, path := range paths { req, err := http.NewRequest("GET", fmt.Sprintf("http://example.com%s", path), nil) if err != nil { t.Errorf("%v", err) } mux.ServeHTTP(httptest.NewRecorder(), req) } expected := strings.NewReader(` # HELP apiserver_request_total [ALPHA] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, client, and HTTP response contentType and code. # TYPE apiserver_request_total counter apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/healthz",verb="GET",version=""} 1 apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/livez",verb="GET",version=""} 1 apiserver_request_total{client="unknown",code="200",component="",contentType="text/plain; charset=utf-8",dry_run="",group="",resource="",scope="",subresource="/readyz",verb="GET",version=""} 1 `) if err := testutil.GatherAndCompare(legacyregistry.DefaultGatherer, expected, "apiserver_request_total"); err != nil { t.Error(err) } } </ins> func createGetRequestWithUrl(rawUrlString string) *http.Request { url, _ := url.Parse(rawUrlString) return &http.Request{
Code change:
What happened: Provisioning of a volume with failed and this event were created on a pod: The event does not say anything useful and only confuses users. What you expected to happen: Either no event (event on PVC about failed provisioning could be enough) or something generic about "waiting for provisioning to finish". How to reproduce it (as minimally and precisely as possible): Tested on AWS. It should be the same with GCE and other block-based in-tree volumes. StorageClass with PVC requesting RWX (so provisioning fails): pod that uses the PVC. Pod events: Anything else we need to know?: I've been able to track down what happens: Scheduler adds to the PVC Provisioner tries to create a volume for the PVC and fails. The annotation is removed in  The scheduler expects that the annotation exists here: I am not sure how to fix it though. Ignoring the error might be the easiest thing to do. Environment: Kubernetes version (use ): today's master /sig storage /sig scheduling /assign
yes, the error message is confusing. "FailedScheduling" event will be emitted if the scheduler failed to schedule the pod. How about wrapping the internal error message in function, e.g. ? Users will know the pod failed because pod volumes not bound successfully. Sometimes, users can't just wait for the scheduler to recover from the error state, manual intervention might be required. The internal reason will be useful. In this scenario, .
's suggestion sounds good to me

Related discussion:
text: return err } <del> return wait.Poll(time.Second, b.bindTimeout, func() (bool, error) { </del> <ins> err = wait.Poll(time.Second, b.bindTimeout, func() (bool, error) { </ins> b, err := b.checkBindings(assumedPod, bindings, claimsToProvision) return b, err }) <ins> if err != nil { pvcName := "" if len(claimsToProvision) > 0 { pvcName = claimsToProvision[0].Name } return fmt.Errorf("Failed to bind volumes: provisioning failed for PVC %q: %v", pvcName, err) } return nil </ins> } func getPodName(pod *v1.Pod) string {
Code change:
<!-- 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: The kubelet metrics related to , except for one, are missing from the kubelet metric endpoint. This applies to these metrics: What you expected to happen: I expect that the metrics mentioned above should be found in the endpoint on the kubelet. How to reproduce it (as minimally and precisely as possible): Run kubelet with a valid , and (defaults to true). or run the node e2e tests: Anything else we need to know?: All e2e tests related to DynamicKubeletConfig fails in master (and in v1.16): This bug/error was introduced in Environment: Kubernetes version (use ): && Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /cc logicalhan tallclair mtaufen
/cc
/assign WIP proof of concept solution to fix (make it a bit easier to understand the problem) here:
/assign
edit: I misunderstood the issue. discussed with offline, and he has an idea to restore previous behavior
That sounds perfect! He answered in the PR, so hopefully we can get this working again. I have wrapped my head around this issue for quite a few hours now, so I understand that it is kinda hard to understand by just reading this issue. Here is some more background info that hopefully makes sense.
/priority important-soon /milestone v1.17
Looks like the CI jobs are cleaning up now! ! Finally down to single digit number test failures, and away from the 30+ :smile:

Related discussion:
text: } } <del> // If the kubelet config controller is available, and dynamic config is enabled, start the config and status sync loops if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) && len(s.DynamicConfigDir.Value()) > 0 && kubeDeps.KubeletConfigController != nil && !standaloneMode && !s.RunOnce { if err := kubeDeps.KubeletConfigController.StartSync(kubeDeps.KubeClient, kubeDeps.EventClient, string(nodeName)); err != nil { return err } } </del> if kubeDeps.Auth == nil { auth, err := BuildAuth(nodeName, kubeDeps.KubeClient, s.KubeletConfiguration) if err != nil {
Code change:
<!-- 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: The kubelet metrics related to , except for one, are missing from the kubelet metric endpoint. This applies to these metrics: What you expected to happen: I expect that the metrics mentioned above should be found in the endpoint on the kubelet. How to reproduce it (as minimally and precisely as possible): Run kubelet with a valid , and (defaults to true). or run the node e2e tests: Anything else we need to know?: All e2e tests related to DynamicKubeletConfig fails in master (and in v1.16): This bug/error was introduced in Environment: Kubernetes version (use ): && Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /cc logicalhan tallclair mtaufen
/cc
/assign WIP proof of concept solution to fix (make it a bit easier to understand the problem) here:
/assign
edit: I misunderstood the issue. discussed with offline, and he has an idea to restore previous behavior
That sounds perfect! He answered in the PR, so hopefully we can get this working again. I have wrapped my head around this issue for quite a few hours now, so I understand that it is kinda hard to understand by just reading this issue. Here is some more background info that hopefully makes sense.
/priority important-soon /milestone v1.17
Looks like the CI jobs are cleaning up now! ! Finally down to single digit number test failures, and away from the 30+ :smile:

Related discussion:
text: return err } <ins> // If the kubelet config controller is available, and dynamic config is enabled, start the config and status sync loops if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) && len(s.DynamicConfigDir.Value()) > 0 && kubeDeps.KubeletConfigController != nil && !standaloneMode && !s.RunOnce { if err := kubeDeps.KubeletConfigController.StartSync(kubeDeps.KubeClient, kubeDeps.EventClient, string(nodeName)); err != nil { return err } } </ins> if s.HealthzPort > 0 { mux := http.NewServeMux() healthz.InstallHandler(mux)
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Change scheduler metric from Gauge to Histogram Why is this needed: is recorded for each preemption attempt. A histogram is better. /sig scheduling /help /good-first-issue
/help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /good-first-issue 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
I can work on this issue.
/assign
I could work on this as well if doesn't have time to work on this.
I am working on it, I will create the initial PR in less than a week. Sorry for the delay.

Related discussion:
text: StabilityLevel: metrics.ALPHA, }, ) <del> PreemptionVictims = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      SchedulerSubsystem, Name:           "pod_preemption_victims", Help:           "Number of selected preemption victims", </del> <ins> PreemptionVictims = metrics.NewHistogram( &metrics.HistogramOpts{ Subsystem: SchedulerSubsystem, Name:      "pod_preemption_victims", Help:      "Number of selected preemption victims", // we think #victims>50 is pretty rare, therefore [50, +Inf) is considered a single bucket. Buckets:        metrics.LinearBuckets(5, 5, 10), </ins> StabilityLevel: metrics.ALPHA, }) PreemptionAttempts = metrics.NewCounter(
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Change scheduler metric from Gauge to Histogram Why is this needed: is recorded for each preemption attempt. A histogram is better. /sig scheduling /help /good-first-issue
/help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /good-first-issue 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
I can work on this issue.
/assign
I could work on this as well if doesn't have time to work on this.
I am working on it, I will create the initial PR in less than a week. Sorry for the delay.

Related discussion:
text: sched.Recorder.Eventf(victim, preemptor, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by %v/%v on node %v", preemptor.Namespace, preemptor.Name, nodeName) } <del> metrics.PreemptionVictims.Set(float64(len(victims))) </del> <ins> metrics.PreemptionVictims.Observe(float64(len(victims))) </ins> } // Clearing nominated pods should happen outside of "if node != nil". Node could // be nil when a pod with nominated node name is eligible to preempt again,
Code change:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.

Related discussion:
text: func ValidatePolicy(policy schedulerapi.Policy) error { var validationErrors []error <ins> priorities := make(map[string]schedulerapi.PriorityPolicy, len(policy.Priorities)) </ins> for _, priority := range policy.Priorities { if priority.Weight <= 0 || priority.Weight >= framework.MaxWeight { validationErrors = append(validationErrors, fmt.Errorf("Priority %s should have a positive weight applied to it or it has overflown", priority.Name)) } <ins> validationErrors = append(validationErrors, validatePriorityRedeclared(priorities, priority)) } predicates := make(map[string]schedulerapi.PredicatePolicy, len(policy.Predicates)) for _, predicate := range policy.Predicates { validationErrors = append(validationErrors, validatePredicateRedeclared(predicates, predicate)) </ins> } binders := 0
Code change:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.

Related discussion:
text: }}, expected: errors.New("kubernetes.io/foo is an invalid extended resource name"), }, <ins> { name: "invalid redeclared custom predicate", policy: api.Policy{ Predicates: []api.PredicatePolicy{ {Name: "customPredicate1", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label1"}}}}, {Name: "customPredicate2", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label2"}}}}, }, }, expected: errors.New("Predicate 'customPredicate2' redeclares custom predicate 'ServiceAffinity', from:'customPredicate1'"), }, { name: "invalid redeclared custom priority", policy: api.Policy{ Priorities: []api.PriorityPolicy{ {Name: "customPriority1", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label1"}}}, {Name: "customPriority2", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label2"}}}, }, }, expected: errors.New("Priority 'customPriority2' redeclares custom priority 'ServiceAntiAffinity', from:'customPriority1'"), }, </ins> } for _, test := range tests {
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: cloud-provider-openstack jobs Which test(s) are failing: hack/local-up- itself fails. Since when has it been failing: Recent change , checks for node ready by doing a grep of KUBELETHOST. But when HOSTNAMEOVERRIDE is set , its unable to find the ip and exits. Testgrid link: Reason for failure: Anything else we need to know:
Repalce KUBELETHOST with HOSTNAMEOVERRIDE shoud fix this issue, I have created a pull request
Thanks. But what if HOSTNAME_OVERRIDE is not set , then again it would fail? I guess its optional parameter
cc
If not set, the default value is 127.0.0.1, won't fail
Hi ramineni, nodpad is correct. HOSTNAME_OVERRIDE do have default value which is 127.0.0.1.
Thanks. Then grep HOSTNAME_OVERRIDE is ideal solution. That would work for me. Hopefully PR gets merged soon

Related discussion:
text: function wait_node_ready(){ # check the nodes information after kubelet daemon start local nodes_stats="${KUBECTL} --kubeconfig '${CERT_DIR}/admin.kubeconfig' get nodes" <del> local node_name=$KUBELET_HOST </del> <ins> local node_name=$HOSTNAME_OVERRIDE </ins> local system_node_wait_time=30 local interval_time=2 kube::util::wait_for_success "$system_node_wait_time" "$interval_time" "$nodes_stats | grep $node_name"
Code change:
What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help

Related discussion:
text: disablePreemption        bool percentageOfNodesToScore int32 enableNonPreempting      bool <del> lastProcessedNodeIndex   int </del> <ins> nextStartNodeIndex       int </ins> } // snapshot snapshots scheduler cache and node infos for all fit and priority