jiebi/CodeConvo huggingface dataset:
Change:
- resource - subresource - version <ins> - name: apiserver_response_sizes help: Response size distribution in bytes for each group, version, verb, resource, subresource, scope and component. type: Histogram stabilityLevel: STABLE labels: - component - group - resource - scope - subresource - verb - version buckets: - 1000 - 10000 - 100000 - 1e+06 - 1e+07 - 1e+08 - 1e+09 </ins> - name: apiserver_storage_objects help: Number of stored objects at the time of last check split by kind. type: Gauge

Discussion:
I would like to propose the graduation of the following apiserver metrics from alpha to stable: With the exception of the metric these metrics have been stable for 2 years. The metric has been stable for 12 months.
/sig api-machinery /sig instrumentation
/assign /triage accepted
I'm okay with promoting all of these except I am hesitant about since it is relatively new. Can we omit that one?
I agree with the metric was patched a year ago as part of , so it would be best to wait a bit more until the majority of Kubernetes users catch up to the patched version and start using the new version of the metric in production.
A couple of renaming suggestions, since it is important to get it right before graduation: apiserverresponsesizes =apiserverresponsesizebytes aggregatorunavailableapiservice =aggregatorunavailableapiservices One concern regarding . It was very recently changed but the change was later reverted by In the end, the metric wasn't really changed, but it might raise the concern that some users may still need additional information from this metric so I am on the fence with this one. Side implementation note that we will need to keep in mind if we graduate is that the graduation should only affect the webhook admission metric and not the other, so we will need to pass the stability level to
Thank you and for the feedback. To clarify then, are the decisions to not graduate and final?
I'm actually okay with , the namespace addition was recent but it was a bad idea and was reverted. It has otherwise been in use for quite some time, so I'd be comfortable with promoting it.
I'm willing to make a PR for this one
+1 it wasn't a hard no from my side, just wanted to raise some concerns in case anyone had an objection.
/assign /unassign
Thank you for the feedback, and To summarize, we are in agreement to graduate all but the metric. Please correct me if I'm wrong.
/cc
since all the three metrics that are created with this function are graduating to stable, do you think I should still pass the to the function or should I just set the metrics created by this functions as stable by default? update: Seems like is designed to parse whatever's in front of . So putting a variable there (that is passed to the function) will cause the script to fail. Please correct me if I'm wrong.

update: Even setting the metrics to be stable by default will cause the script to fail and you'll get an error saying for the following line: It appears that the name of the stable metrics should be given to that object as a string and using the output of a function ( in this case) will cause the script to fail.
The PR is ready to be reviewed:
Change:
var extenders []algorithm.SchedulerExtender if len(policy.ExtenderConfigs) != 0 { ignoredExtendedResources := sets.NewString() <ins> var ignorableExtenders []algorithm.SchedulerExtender </ins> for ii := range policy.ExtenderConfigs { klog.V(2).Infof("Creating extender with config %+v", policy.ExtenderConfigs[ii]) extender, err := core.NewHTTPExtender(&policy.ExtenderConfigs[ii]) if err != nil { return nil, err } <del> extenders = append(extenders, extender) </del> <ins> if !extender.IsIgnorable() { extenders = append(extenders, extender) } else { ignorableExtenders = append(ignorableExtenders, extender) } </ins> for _, r := range policy.ExtenderConfigs[ii].ManagedResources { if r.IgnoredByScheduler { ignoredExtendedResources.Insert(string(r.Name)) } } } <ins> // place ignorable extenders to the tail of extenders extenders = append(extenders, ignorableExtenders...) </ins> predicates.RegisterPredicateMetadataProducerWithExtendedResourceOptions(ignoredExtendedResources) } // Providing HardPodAffinitySymmetricWeight in the policy config is the new and preferred way of providing the value.

Discussion:
What would you like to be : Put non-ignorable extenders ahead of ignorable extenders in genericScheduler#extenders Why is this needed: In genericScheduler#processPreemptionWithExtenders, we iterate over genericScheduler#extenders. If an ignorable extender gives error, the error is ignored and loop continues. It seems we should place non-ignorable extenders ahead of ignorable extenders so that the preemption can bail out early if a non-ignorable extender gives error.
/sig scheduling
Change:
f.PodClient().DeleteSync(burstablePodName, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) f.PodClient().DeleteSync(bestEffortPodName, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) f.PodClientNS(kubeapi.NamespaceSystem).DeleteSyncInNamespace(criticalPodName, kubeapi.NamespaceSystem, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) <ins> err := f.ClientSet.SchedulingV1().PriorityClasses().Delete(systemCriticalPriorityName, &metav1.DeleteOptions{}) framework.ExpectNoError(err) </ins> // Log Events logPodEvents(f) logNodeEvents(f)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /reopen 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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
case statInfo.Mode().IsRegular(): pod, err := s.extractFromFile(path) if err != nil { <del> glog.Errorf("Can't process manifest file %q: %v", path, err) </del> <ins> if !os.IsNotExist(err) { glog.Errorf("Can't process manifest file %q: %v", path, err) } </ins> } else { pods = append(pods, pod) }

Discussion:
<!-- 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: sometimes use vi edit /etc/kubernetes/manifests/kube-, apiserver will be kill, but not restart again; but sometimes is ok, kube-apiserver will restart.(test 10 times, and 2 times problem found) but if I move this file out of /etc/kubernetes/manifests/, wait for moment, and then move back, apiserver restart, problem fix. What you expected to happen: edit /etc/kubernetes/manifests/kube-, apiserver auto-update How to reproduce it (as minimally and precisely as possible): a k8s cluster. kube- by vi editor. apiserver status. Anything else we need to know?: any thing you want to know, please ping me. Environment: Kubernetes version (use ):Cloud provider or hardware configuration:none OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kubeadm Others:none
/sig node
could you help to fix this problem?
You mean changing file in folder ? Seems did not catch your changes. Any logs from ?
yes, and I have try again, got this:
but why is 4913, not the file kube- I have try several times, and got the same error message. by the way, following code, I arrive here: (), seem here to watch the file change.
Thanks for finding this bug. I will take a look.
after I add glog.Errorf("Be careful, I am going to check: %v", e.Name) to print log, I found this: has read the right file /etc/kubernetes/kube- must parse to pod success, because it knows the mirror older kube-apiserver is outdated add in ():
Right. was deleted first. That's why so many occurred afterwards. And the new pod for cannot be created as well. Seems we have to make a special treatment for , but this will be kind of ugly. Any suggestions?

relatived to but found in kubernetes v1.8.3 further more, following the code, I have found that create mirror pod failed, because kubelet can't connect to apiserver, and the code already filter the temp file .kube- So, the problem must be why kubelet can't start kube-apiserver static pod. But I can't find out where to create the static pod in code, Could you help?
is in (), I will continue to find out why kube-apiserver not start.
Good job! Thanks for the update. I prefer to move the discussion to .
It's a good idea, discussion in .
/close Move discussion to .
Change:
exec := exec.New() out, err := exec.Command(nsenterPath, args...).CombinedOutput() if err != nil { <del> glog.V(2).Infof("Failed findmnt command: %v", err) </del> <ins> glog.V(2).Infof("Failed findmnt command for path %s: %v", file, err) </ins> // Different operating systems behave differently for paths which are not mount points. // On older versions (e.g. 2.20.1) we'd get error, on newer ones (e.g. 2.26.2) we'd get "/". // It's safer to assume that it's not a mount point.

Discussion:
Currently, there many error messages in that do not contain any context. This means that these messages are basically meaningless in real systems where many pods may be on a node. Examples: Every error message in this file should identify the path that the message is in relation to.
Can you handle this, since you most recently touched in ?
Change:
} loadBalancerName := cloudprovider.GetLoadBalancerName(service) <del> pool, err := gce.GetTargetPool(loadBalancerName, gce.region) if err != nil { return err } existing := sets.NewString() for _, instance := range pool.Instances { existing.Insert(hostURLToComparablePath(instance)) } return gce.updateTargetPool(loadBalancerName, existing, hosts) </del> <ins> return gce.updateTargetPool(loadBalancerName, hosts) </ins> } // ensureExternalLoadBalancerDeleted is the external implementation of LoadBalancer.EnsureLoadBalancerDeleted

Discussion:
<!-- 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 /sig network /area cloudprovider What happened: The cloud provider interface that should . The GCE provider does this for but not for . Every other in-tree provider implements by fully updating the load balancer including updated backend nodes: , , , And the following out-of-tree providers do as well and Oracle (not oss yet). What you expected to happen: I expect that all cloud providers implement by creating or fully updating the load balancer if it already exists. Related discussion: /cc
/assign Make sense to make implementation in GCE consistent with others for the ease of up-coming service controller enhancement. This sounds like a 1.10 task.
is this task blocking you on another attempt at refactoring the service controller sync logic?
yup
Change:
scoreWithNormalizePlugin1         = "score-with-normalize-plugin-1" scoreWithNormalizePlugin2         = "score-with-normalize-plugin-2" scorePlugin1                      = "score-plugin-1" <ins> scorePlugin2                      = "score-plugin-2" </ins> pluginNotImplementingScore        = "plugin-not-implementing-score" preFilterPluginName               = "prefilter-plugin" preFilterWithExtensionsPluginName = "prefilter-with-extensions-plugin"

Discussion:
Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.
Change:
"k8s.io/kubectl/pkg/util/templates" ) <ins> const ( MsgNotLabeled = "not labeled" MsgLabeled    = "labeled" MsgUnLabeled  = "unlabeled" ) </ins> // LabelOptions have the data required to perform the label operation type LabelOptions struct { // Filename options

Discussion:
Currently, the cmd output msg is not distinguished between label and unlabel (using suffix ), both of them response . To distinguish between label and unlabel msg: , just like .
/sig cli
/triage accepted
Change:
"reflect" "sync" "testing" <ins> "time" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The scheduler places unschedulable pods in "unschedulabe" queue and retries them only when certain events happen that could potentially make them schedulable. This logic works well in almost all scenarios, but inevitable race condition in large distributed systems, could potentially cause some events to be seen before pods are to the unschedulable queue. If this happens, pods may be left in the unschedulable queue and not be retried. Such scenarios should be rare and even if they occur, usually there are other events that trigger a retry and cover them. However, if such scenarios happen in smaller and low churn clusters, other events may not be seen for a while and pods may be stuck in the unschedulable queue for a long time. The scheduling queue () has a method that is triggered every second to move backed off pods to the active queue. We should add another go routine that is triggered every 30 seconds and moves pods whose last schedule time is older than 1 minute from "unschedulble" queue to the active queue. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug I don't know if this should be marked as a bug. I don't have any report of such issue. It is more of a precaution to prevent issues. /sig scheduling
I am worried if this will lead to continuous repeated scheduling failures?
What is the problem with repeated scheduling failures? The scheduler had a FIFO until recently. It used to keep retrying unschedulable pods all the time.
can I take this?
Sure, thanks!
GitHub didn't allow me to assign the following users: denkensk. Note that only and repo collaborators can be assigned. For more information please see <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
It increases the schedule possibility of unschedulble pods and the chances of scheduling failures. Should we also consider latter?
Change:
nodes                   []string kubeClient              client.Interface kubeletClient           client.KubeletClient <ins> recorder                record.EventRecorder </ins> registerRetryCount      int podEvictionTimeout      time.Duration deletingPodsRateLimiter util.RateLimiter

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.
Change:
} if docsForTypes != nil && len(docsForTypes) > 0 { <del> if err := pkg_runtime.WriteSwaggerDocFunc(docsForTypes, funcOut); err != nil { </del> <ins> if err := kruntime.WriteSwaggerDocFunc(docsForTypes, funcOut); err != nil { </ins> fmt.Fprintf(os.Stderr, "Error when writing swagger documentation functions: %sn", err) os.Exit(-1) }

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
t.Errorf("did not set resources: %s", buf.String()) } } <ins> func TestSetMultiResourcesLimitsLocal(t *testing.T) { f, tf, codec, ns := cmdtesting.NewAPIFactory() tf.Client = &fake.RESTClient{ GroupVersion:         legacyscheme.Registry.GroupOrDie(api.GroupName).GroupVersion, NegotiatedSerializer: ns, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { t.Fatalf("unexpected request: %s %#vn%#v", req.Method, req.URL, req) return nil, nil }), } tf.Namespace = "test" tf.ClientConfig = &restclient.Config{ContentConfig: restclient.ContentConfig{GroupVersion: &legacyscheme.Registry.GroupOrDie(api.GroupName).GroupVersion}} buf := bytes.NewBuffer([]byte{}) cmd := NewCmdResources(f, buf, buf) cmd.SetOutput(buf) cmd.Flags().Set("output", "name") cmd.Flags().Set("local", "true") mapper, typer := f.Object() tf.Printer = &printers.NamePrinter{Decoders: []runtime.Decoder{codec}, Typer: typer, Mapper: mapper} opts := ResourcesOptions{FilenameOptions: resource.FilenameOptions{ Filenames: []string{"../../../../test/fixtures/pkg/kubectl/cmd/set/multi-resource-yaml.yaml"}}, Out:               buf, Local:             true, Limits:            "cpu=200m,memory=512Mi", Requests:          "cpu=200m,memory=512Mi", ContainerSelector: "*"} err := opts.Complete(f, cmd, []string{}) if err == nil { err = opts.Validate() } if err == nil { err = opts.Run() } if err != nil { t.Fatalf("unexpected error: %v", err) } expectedOut := "replicationcontrollers/first-rcnreplicationcontrollers/second-rcn" if buf.String() != expectedOut { t.Errorf("expected out:n%snbut got:n%s", expectedOut, buf.String()) } } </ins>

Discussion:
<!-- 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: my yaml: exec kubectl set resources command,just update first object: 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:
/sig cli
/kind bug
/assign
Change:
# Enable features ENABLE_FEATURE_GATES="" <ins> VERSION_OVERRIDE="" if [[ "${CUSTOM_VERSION_SUFFIX:-}" != "" ]]; then VERSION_OVERRIDE="--version=$("${THIS_PLATFORM_BIN}/kube-apiserver" --version | awk '{print $2}')${CUSTOM_VERSION_SUFFIX:-}" fi </ins> "${THIS_PLATFORM_BIN}/kube-apiserver"  <ins> ${VERSION_OVERRIDE:+"${VERSION_OVERRIDE}"}  </ins> --bind-address="127.0.0.1"  --authorization-mode="${AUTHORIZATION_MODE}"  --secure-port="${SECURE_API_PORT}" 

Discussion:
Starting in 1.31, --version no longer works to modify the build ID of the running components. /kind regression /priority important-soon Running kube-apiserver v1.31.0 with ignores the modified build ID and reports In 1.28, 1.29, and 1.30 (since ), this allowed modifying the build ID of the running server. /sig api-machinery /assign Run v1.31.0 with No response 31.0 n/a <details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I think this broke in DefaultBuildEffectiveVersion() is grabbed in NewAPIServerCommand(), before the flag is parsed, so the GitVersion propagated into the snapshot effectiveVersion doesn't honor
cc