jiebi/CodeConvo huggingface dataset:
Change:
pod := podInfo.Pod scheduleResult, err := sched.SchedulePod(ctx, fwk, state, pod) if err != nil { <ins> defer func() { metrics.SchedulingAlgorithmLatency.Observe(metrics.SinceInSeconds(start)) }() </ins> if err == ErrNoNodesAvailable { status := framework.NewStatus(framework.UnschedulableAndUnresolvable).WithError(err) return ScheduleResult{nominatingInfo: clearNominatedNode}, podInfo, status

Discussion:
schedulingCycle only reports algorithmduration when it's a successful scheduling attempt: Also report scheduling algorithm latency when the pods is unschedulable Create a Pod that is unschedulable (perhaps node selector for a node that doesn't exist) and observe metrics No response <detailsANY </details<detailsANY </details<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
/assign
let me try
Change:
type ILBOptions struct { // AllowGlobalAccess Indicates whether global access is allowed for the LoadBalancer AllowGlobalAccess bool <ins> // SubnetName indicates which subnet the LoadBalancer VIPs should be assigned from SubnetName string </ins> } // GetLoadBalancerAnnotationAllowGlobalAccess returns if global access is enabled

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: ILB ip addresses come from the subnet that the K8s cluster uses. There is no ability to specify a different subnet. What you expected to happen: ILB ip addresses should be allocated from a different subnet if specified. 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: GCE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/area platform/gce /assign
/sig network
Change:
case syncErr == nil: // No error; requeue at the regular resync interval. p.workQueue.Enqueue(uid, wait.Jitter(p.resyncInterval, workerResyncIntervalJitterFactor)) <ins> case strings.Contains(syncErr.Error(), NetworkNotReadyErrorMsg): // Network is not ready; back off for short period of time and retry as network might be ready soon. p.workQueue.Enqueue(uid, wait.Jitter(backOffOnTransientErrorPeriod, workerBackOffPeriodJitterFactor)) </ins> default: // Error occurred during the sync; back off and then retry. p.workQueue.Enqueue(uid, wait.Jitter(p.backOffPeriod, workerBackOffPeriodJitterFactor))

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node
Change:
results <- err return } <ins> discoveryURL.Path = "/apis/" + apiService.Spec.Group + "/" + apiService.Spec.Version </ins> errCh := make(chan error) go func() { <ins> // be sure to check a URL that the aggregated API server is required to serve </ins> newReq, err := http.NewRequest("GET", discoveryURL.String(), nil) if err != nil { errCh <- err

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: runs as a APIService but it fails with and the endpoint returns on kubernetes clusters with v1.15. It works with all previous cluster versions perfectly but gives the following status on v1.15 but I also don't see any changes in Releasing notes that effects APIService What you expected to happen: APISerice should run correctly and the endpoint should be responding. How to reproduce it (as minimally and precisely as possible): Linkerd dosent have to be installed to check this, and discovery happens directly at the url without any communication with the underlying mesh. In the repo, running this generates the required certs and applies the config to the cluster To check the status of the APIService, can be used Anything else we need to know?: I did check with clean 1.15 clusters and its the same. I also don't see any changes in 1.15 release notes that effects APIServices. 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: Testing is done on kind but its the same with minikube
/sig api-machinery
that sounds bad.. i didnt remember any breaking change except for making the port confiugrable.. /cc
what does interrogating the service directly return?
On Clusters 1.15, where the status of APIService is it gives On Clusters 1.14.3, where the status of APIService is it gives
looks related If the aggregated server returns non-200 status code, it is treated as unavailable. what endpoint is checked by the available controller?
i skimmed implementation from smi-metrics.. it only serves on prefixes so when the available controller checks the root endpoint it returns a 404.
but then it dosent fail on clusters running v1.14, In that version the apiService is marked as
fixed by , picked to 1.15.x in , will be in v1.15.1
Awesome Thanks for the quick fix :)
Change:
configDir string } <del> // NewFSLoader returns a Loader that loads a KubeletConfiguration from the files in `configDir` func NewFSLoader(fs utilfs.Filesystem, configDir string) (Loader, error) { </del> <ins> // NewFsLoader returns a Loader that loads a KubeletConfiguration from the files in `configDir` func NewFsLoader(fs utilfs.Filesystem, configDir string) (Loader, error) { </ins> _, kubeletCodecs, err := kubeletscheme.NewSchemeAndCodecs() if err != nil { return nil, err

Discussion:
From in The most important things I want to see through node e2e tests: 1) the kubelet is started from last-known-good-config file 2) kubelet can download the new config properly to the node; and restart itself from the new config file 3) kubelet can mark the config bad properly after several round of crashing caused the bad config 4) Kubelet can roll back the last-known-good-config and restart itself from that good one 5) kubelet can properly reports its configuration status Note: (2) is covered by existing e2enode tests (1, 4, 5) were covered by the , all of which I plan to turn into automated tests after this PR merges - but I'm trying not to increase the size of this PR any further ~(3) we need to figure out how to test this. I don't want to rely on a "valid" config that causes a crash loop - because the very existence of such a config should be viewed as a bug. I also don't want to include a "please crash loop for our tests" field in the config, because that's an ugly API. The best solution is not clear here.~ We decided to remove crash-loop detection, see . Filing this issue to track this work: into e2e_node tests [x] remote config [x] local (from file) config [x] ~test the crash-loop detection~ removed, see above /cc
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.8 milestone for more than 7 days: kind: Must specify exactly one of [, , ]. priority: Must specify exactly one of [, , ]. Removing it from the milestone. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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
/remove-lifecycle stale
The test cases in the OP have been covered by our e2e_node tests for a while.
Change:
"github.com/robfig/cron/v3" batchv1 "k8s.io/api/batch/v1" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime"

Discussion:
Changing the label on a job template in a CronJob causes any Jobs held by the successful/failed history parameters to stop being tracked, so they never get cleaned up. Jobs with labels that don't match the (upgraded) CronJob, but still have an owner reference, should be subject to the history limit. a CronJob with a job template containing label , and non-zero history limit the CronJob to run and generate some Jobs (default 3 successful, 1 failed) the CronJob with a job template containing label the CronJob to run and generate some more Jobs there are more than 3 successful Jobs/1 failed Job! I believe this is the relevant code: The CronJob controller finds Jobs that it should care about by matching on the labels in the job template, this obviously breaks if the labels in the job template change. 21 Self-hosted No response No response No response No response_
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 apps
Experiencing another side-effect of this bug. If job template labels are updated while a cronjob has status (a scheduled job is running), then that cronjob gets stuck in . The cause seems to be the same as describes: once the job template labels are updated, cronjob controller V2 loses track of the jobs with the old labels, and therefore never updates the status of that active cronjob to indicate that the scheduled job has completed.
/assign
Change:
t.Fatal(err) } <del> // Start informer factory after initialization informerFactory.Start(ctx.Done()) // Feed testing data and wait for them to be synced </del> <ins> t.Log("Feed testing data and wait for them to be synced") </ins> client.StorageV1().StorageClasses().Create(ctx, immediateSC, metav1.CreateOptions{}) client.StorageV1().StorageClasses().Create(ctx, waitSC, metav1.CreateOptions{}) if item.node != nil {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: The unit test Which test(s) are flaking: Testgrid link: Reason for failure: In volume scheduling, we maintain internal caches that watch for PV/PVC events. However, we don't have a method to wait for them to be synced in UT. When the cache in the informer factory is synced but the execution of registered handlers may not finish. <!-- In production, this is not a problem. Even if the scheduler marks the pod uncacheable due to the stale cache in PVAssumeCache/PVCAssumeCache, the pod will be moved to the active queue later as the scheduler . related: --Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig scheduling /sig storage
Even if I check the PV/PVC assume cache and wait for PV/PVC objects to be into the cache, the PV/PVC objects may not be . It seems that the shared informer with the fake client has a bug that registered event handlers may not be called (or handlers are not registered successfully).
The share informer with the fake client may miss events of objects which are created before caches are synced. it's better to create testing objects before starting the informers
Although the event handlers may not finish when the caches were synced in theory, however, it seems it's not necessary to wait for PV/PVC assume cache to be synced practically. I've run a thousand times (parallel: 10) with locally and no failures.
Change:
framework.Logf("Status.Condition: %#v", statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1]) }) <del> ginkgo.It("should apply an update to a Namespace", func() { </del> <ins> /* Release: v1.26 Testname: Namespace, apply update to a namespace Description: When updating the namespace it MUST succeed and the field MUST equal the new value. */ framework.ConformanceIt("should apply an update to a Namespace", func() { </ins> var err error var updatedNamespace *v1.Namespace ns := f.Namespace.Name

Discussion:
[X] Test approval issue: [X] Test PR: 27 Aug 2022 [x] Two weeks soak end date: 9 Sept 2022 [x] Test promotion PR: According to this APIsnoop query, there are still a remaining Namespace endpoint which is untested. replaceCoreV1Namespace Using a number of existing e2e test practices a new has been created for 1 Namespace endpoint. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /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
Change:
if sp.failScore { return 0, framework.NewStatus(framework.Error, fmt.Sprintf("injecting failure for pod %v", p.Name)) } score := 10 <del> if nodeName == sp.highScoreNode { </del> <ins> if sp.numCalled == 1 { // The first node is scored the highest, the rest is scored lower. sp.highScoreNode = nodeName </ins> score = 100 } return score, nil

Discussion:
What happened: The new TestScorePlugin for the scheduler framework is flaky How to reproduce it (as minimally and precisely as possible): An example: Anything else we need to know?: The test evaluates that a pod should be scheduled on specific node with a higher score. I think the test sometimes fails because the higher score node that the test creates didn't propagate yet to the scheduler (i.e., the node exists in etcd, but scheduler hasn't been notified that it exists yet, and so it is not evaluated at all). /kind bug /sig scheduling /assign
/kind flake
Change:
func init() { api.Scheme.AddDefaultingFuncs( <ins> func(obj *ReplicationController) { if len(obj.DesiredState.ReplicaSelector) == 0 { obj.DesiredState.ReplicaSelector = obj.DesiredState.PodTemplate.Labels } if len(obj.Labels) == 0 { obj.Labels = obj.DesiredState.PodTemplate.Labels } }, </ins> func(obj *Volume) { if util.AllPtrFieldsNil(&obj.Source) { obj.Source = VolumeSource{

Discussion:
It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.
Change:
} list := &unstructured.UnstructuredList{} <ins> list.SetRemainingItemCount(entireList.GetRemainingItemCount()) </ins> list.SetResourceVersion(entireList.GetResourceVersion()) <ins> list.SetContinue(entireList.GetContinue()) </ins> list.GetObjectKind().SetGroupVersionKind(listGVK) for i := range entireList.Items { item := &entireList.Items[i]

Discussion:
The fake dynamic client does not support mock pagination or the self link. Add ability to propagate the metadata fields from a mock unstructured list to the served list by the fake lister. Repro linked in the MR x-ref. No response <details</detailsN/A N/A <detailsN/A </details<detailsN/A </details<detailsN/A </details
/sig api-machinery
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
) const ( <del> errBadCertificate    = "Get .*: remote error: tls: bad certificate" </del> <ins> errBadCertificate    = "Get .*: remote error: tls: (bad certificate|unknown certificate authority)" </ins> errNoConfiguration   = "invalid configuration: no configuration has been provided" errMissingCertPath   = "invalid configuration: unable to read %s %s for %s due to open %s: .*" errSignedByUnknownCA = "Get .*: x509: .*(unknown authority|not standards compliant|not trusted)"

Discussion:
Using the Go 1.21 dev branch, FORCEHOSTGO=y make test fails because the TLS bad certificate error has gotten more specific in Go 1.21. Test should pass. Use the command above with the Go 1.21 dev branch as your in your PATH. Here is the fix: HEAD N/A N/A N/A N/A N/A
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
Thank you very much /priority important-soon /cc The fix is already reported on the description, so this is an easy PR for people willing to contribute /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Thank you very much /priority important-soon /cc 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
/sig architecture
/assign