jiebi/CodeConvo huggingface dataset:
Change:
package benchmark import ( <ins> "encoding/json" "flag" "fmt" "io/ioutil" "math" "path" "sort" "time" dto "github.com/prometheus/client_model/go" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime/schema" coreinformers "k8s.io/client-go/informers/core/v1" clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest" <ins> "k8s.io/component-base/metrics/legacyregistry" "k8s.io/klog" </ins> "k8s.io/kubernetes/test/integration/util" ) <ins> const ( dateFormat                = "2006-01-02T15:04:05Z" throughputSampleFrequency = time.Second ) var dataItemsDir = flag.String("data-items-dir", "", "destination directory for storing generated data items for perf dashboard") </ins> // mustSetupScheduler starts the following components: // - k8s api server (a.k.a. master) // - scheduler

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should allow collecting both default scheduler metrics (Prometheus) and custom metrics easily. At a high level, these collectors should produce a json formatted result which will then be consumed by perf-dash to present in the dashboard. Prometheus metrics We should provide a metrics collector that collects and summarizes default scheduler metrics defined in . To begin with, we can manually pick a list of interesting metrics. Longer term, we could allow configuring the metric list in test definition. already had a PoC . As a reference, is how clusterloader collects scheduler latency metrics. Custom metrics The most important metric is scheduling throughput. is how clusterloader calculates the throughput. We can start with just calculating the average throughput without the percentiles. We may want other custom metrics that are either common to all tests or specific to certain tests. We should allow these custom collectors to be easily and ideally configurable. Why is this needed: Give more insights into scheduler performance. Part of /sig scheduling /assign
/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:
"//pkg/client/clientset_generated/internalclientset:go_default_library", "//pkg/client/clientset_generated/internalclientset/typed/core/internalversion:go_default_library", "//pkg/kubeapiserver/admission:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apiserver/pkg/admission:go_default_library", ],

Discussion:
When a node is deleting a pod, the NodeRestriction admission plugin ensures the pod is bound to the node. It first checks the server cache for the pod. In the case where a pod was created and immediately deleted, it may not yet exist in the server cache. Before forbidding, we should do a live lookup. https://k8s- cc
Change:
- Otherwise, if taking the firewall-based security approach - `--api-servers=http://$MASTER_IP` - `--config=/etc/kubernetes/manifests` <del> - `--cluster-dns=` to the address of the DNS server you will setup (see [Starting Addons](#starting-addons).) </del> <ins> - `--cluster-dns=` to the address of the DNS server you will setup (see [Starting Cluster Services](#starting-cluster-services).) </ins> - `--cluster-domain=` to the dns domain prefix to use for cluster DNS addresses. - `--docker-root=` - `--root-dir=`

Discussion:
has TODOs for how to bring up cluster addons like monitoring and logging. We should fill these in. requested by user:
Change:
// Init the metric for the new zone. klog.Infof("Initializing eviction metric for zone: %v", zone) evictionsNumber.WithLabelValues(zone).Add(0) <ins> evictionsTotal.WithLabelValues(zone).Add(0) </ins> } }

Discussion:
I would like to propose the graduation of the metric from alpha to stable. The metric has been stable for 2 years now.
/sig api-machinery /sig instrumentation
I am willing to do all StabilityLevels from alpha to stable? Is that right?
/assign
- The request is to have the stability level for the metric graduate to stable. If there are other metrics you want to do at the same time that's a bonus, but not part of the request in this issue.
/sig node /remove-sig api-machinery /cc
To be promoted to stable, the metrics would need to be renamed from to in order to follow Prometheus best practices as well as sig-instrumentation naming guidelines.
/cc
/assign
/triage accepted
Change:
package storage import ( <del> utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" "k8s.io/kubernetes/pkg/features" </del> <ins> "context" </ins> "testing" <ins> "time" </ins> <del> "context" </del> "github.com/google/go-cmp/cmp" apiequality "k8s.io/apimachinery/pkg/api/equality" "k8s.io/apimachinery/pkg/api/resource"

Discussion:
pkg/registry/core/persistentvolume/storage TestUpdateStatus unknown No response /sig storage
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
/assign
/priority important-soon as it failed in master blocking
Change:
} // Inject error to underlying layer and check if cacher is not bypassed. <del> backingStorage.err = errDummy </del> <ins> backingStorage.injectError(errDummy) </ins> err = cacher.Get(context.TODO(), "pods/ns/pod-0", storage.GetOptions{ IgnoreNotFound:  true, ResourceVersion: "0",

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted
Change:
) func getNodeSummary() (*kubeletstatsv1alpha1.Summary, error) { <del> req, err := http.NewRequest("GET", *kubeletAddress+"/stats/summary", nil) </del> <ins> kubeletConfig, err := getCurrentKubeletConfig() if err != nil { return nil, fmt.Errorf("failed to get current kubelet config") } req, err := http.NewRequest("GET", fmt.Sprintf("http://%s:%d/stats/summary", kubeletConfig.Address, kubeletConfig.ReadOnlyPort), nil) </ins> if err != nil { return nil, fmt.Errorf("failed to build http request: %v", err) }

Discussion:
There is a todo in the node e2e test suite to obtain the kubelet address from the kubelet config The kubelet address is used in The kubelet flag is itself deprecated, , so we could get it from the kubelet config. /help wanted /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 : There is a todo in the node e2e test suite to obtain the kubelet address from the kubelet config --address 0.0.0.0 The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See for more information.) , so we could get it from the kubelet config. /good-first-issue </details
/sig node
can I give it a try?
/assign knabben
Change:
func VerifyExecInPodSucceed(f *framework.Framework, pod *v1.Pod, shExec string) { _, err := PodExec(f, pod, shExec) if err != nil { <del> if err, ok := err.(uexec.CodeExitError); ok { exitCode := err.ExitStatus() </del> <ins> if exiterr, ok := err.(uexec.CodeExitError); ok { exitCode := exiterr.ExitStatus() </ins> framework.ExpectNoError(err, "%q should succeed, but failed with exit code %d and error message %q", <del> shExec, exitCode, err) </del> <ins> shExec, exitCode, exiterr) </ins> } else { framework.ExpectNoError(err, "%q should succeed, but failed with error message %q",

Discussion:
In a few utility function in current test/e2e/storage/utils, we found that the err variable gets shadowed. Because of this, it might get nil pointer error. See code
fixed by
Change:
import ( "context" "fmt" <del> "net" "strconv" </del> "time" v1 "k8s.io/api/core/v1"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: We want to change ownership of a test from scheduler to network Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Once merges, we will exclude hostPort test on Windows. This is because of how the hostPort test is structured where we are relying on hostNetwork pod to test the communication between hostPort pods. This will not work on Windows as hostNetwork is not supported. I think it is better to have this test in sig-network and test the communication as scheduler should be responsible only for assigning a pod to node. This also ensures that hostPort on Windows is exercised properly. Anything else we need to know: More context
/sig scheduling /sig network cc
/area conformance /area test /sig windows since windows
/triage accepted
Change:
ginkgo.By("Creating a Pod with more than former max resources") pod = newTestPod(podName+"2", getResourceList("600m", "600Mi", "600Gi"), v1.ResourceList{}) <del> _, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(ctx, pod, metav1.CreateOptions{}) </del> <ins> // When the LimitRanger admission plugin find 0 items from the LimitRange informer cache, // it will try to lookup LimitRanges from the local LiveLookupCache which liveTTL is 30s. // If a LimitRange was deleted from the apiserver, informer watch the delete event and then // handle it lead to the informer cache doesn't have any other items, but the local LiveLookupCache // has it and not expired at the same time, the LimitRanger admission plugin will use the // deleted LimitRange to validate the request. So the request will be rejected by the plugin // till the item is expired. // // With the following retry, we can make sure the item is expired and the request will be // validated as expected. err = framework.Gomega().Eventually(ctx, func(ctx context.Context) error { _, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(ctx, pod, metav1.CreateOptions{}) return err }).WithPolling(5 * time.Second).WithTimeout(30 * time.Second).ShouldNot(gomega.HaveOccurred()) </ins> framework.ExpectNoError(err) })

Discussion:
/kind failing-test /sig scheduling This flakes before in and was fixed by . As this test is not flaky a lot, the priority may not be that high. But as this is a conformance test, we'd better to know why this would happen.
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
/assign
Change:
Expect(devId1).To(Not(Equal(devId2))) By("Deleting device plugin.") <del> f.PodClient().Delete(devicePluginPod.Name, &metav1.DeleteOptions{}) </del> <ins> f.ClientSet.CoreV1().Pods(metav1.NamespaceSystem).Delete(devicePluginPod.Name, &metav1.DeleteOptions{}) </ins> By("Waiting for GPUs to become unavailable on the local node") Eventually(func() bool { node, err := f.ClientSet.CoreV1().Nodes().Get(framework.TestContext.NodeName, metav1.GetOptions{})

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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:
// TestPermitPlugin tests invocation of permit plugins. func TestPermitPlugin(t *testing.T) { // Create a plugin registry for testing. Register only a permit plugin. <del> registry := framework.Registry{permitPluginName: NewPermitPlugin} </del> <ins> perPlugin := &PermitPlugin{} registry := framework.Registry{permitPluginName: NewPermitPlugin(perPlugin)} </ins> // Setup initial permit plugin for testing. plugins := &schedulerconfig.Plugins{

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestPreemptWithPermitPlugin Since when has it been failing: 13:30 PST, Sep 9, 2019 Testgrid link: Reason for failure: Need investigations. Anything else we need to know: /sig scheduling
Another flaky It happens at 2019-08-06 05:43:47 +0000 UTC
The above repeated for 30 seconds.
I checked the code and log again. I think the reason is as following: When scheduler preempted , it failed to delete the pod(same as the case for , there might be something wrong with etcd), so it could not schedule because had not been deleted successfully.
/assign Find the root cause now, will send a PR soon.
Thanks for your work! Not sure whether you are still investigating it, the flaky test is impacting many PRs now, so I send a PR for it now, sorry for it.
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" <ins> "k8s.io/client-go/kubernetes" </ins> clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest" "k8s.io/kubernetes/pkg/controller/endpoint"

Discussion:
with Selector is created is removed Endpoints and EndpointSlice controllers do not clean up Endpoint(Slice)s mirroring controller starts mirroring the Endpoints resource originally created by the Endpoints controller is back to the Service backing Service change created by mirroring controller still references original IP from step 4 At least one of the following: Endpoints and EndpointSlices to be cleaned up when the Service has the selector removed () mirrored EndpointSlice to be removed when the Service has a selector back See "What Happened" No response Most noticeable in Kubernetes 1.19+ since that's when kube-proxy starts reading from EndpointSlices by default. Any No response No response No response No response
/sig network /triage accepted /priority important-soon /cc
/assign
Change:
noScheduleTaints      = []v1.Taint{{Key: "dedicated", Value: "user1", Effect: "NoSchedule"}} ) <ins> var ( nodeNotReady = []v1.Taint{{ Key:       metav1.TaintNodeNotReady, Effect:    v1.TaintEffectNoExecute, TimeAdded: metav1.Now(), }} nodeUnreachable = []v1.Taint{{ Key:       metav1.TaintNodeUnreachable, Effect:    v1.TaintEffectNoExecute, TimeAdded: metav1.Now(), }} ) </ins> func getKey(ds *extensions.DaemonSet, t *testing.T) string { if key, err := controller.KeyFunc(ds); err != nil { t.Errorf("Unexpected error getting key for ds %v: %v", ds.Name, err)

Discussion:
When writing DaemonSets we decided that they shouldn't be deleted by NodeController in case of Node problems. Now that we're moving to using taints and taint-based evictions (NC will just taint Nodes and the rest will be done by generic taint-eviction mechanism) we need to add infinite toleration for those taints to DaemonSets to keep this behavior. cc
Off the top of my head, I think the best way to implement this is to modify the , to special-case DaemonSet pods and add infinite tolerationSeconds to them. (See definition of field in the API for how to do this.) do you think you can do this? It should be a simple change. cc/ BTW the feature Marek described will be alpha in 1.6, but nobody will be able to use it (without breaking DaemonSet) unless this request is implemented. So the 1.6 milestone tag is appropriate.
Why wouldn't the daemon set controller special case that?
Yeah, I guess that's probably better - have the DaemonSet controller create pods with the toleration.
I can do this, and yes, in the DaemonSet controller.
Change:
return deviceName, diskUUID, nil } <ins> func getNextUnitNumber(devices object.VirtualDeviceList, c types.BaseVirtualController) (int32, error) { // get next available SCSI controller unit number var takenUnitNumbers [SCSIDeviceSlots]bool takenUnitNumbers[SCSIReservedSlot] = true key := c.GetVirtualController().Key for _, device := range devices { d := device.GetVirtualDevice() if d.ControllerKey == key { if d.UnitNumber != nil { takenUnitNumbers[*d.UnitNumber] = true } } } for unitNumber, takenUnitNumber := range takenUnitNumbers { if !takenUnitNumber { return int32(unitNumber), nil } } return -1, fmt.Errorf("SCSI Controller with key=%d does not have any avaiable slots (LUN).", key) } </ins> func getSCSIController(vmDevices object.VirtualDeviceList, scsiType string) *types.VirtualController { // get virtual scsi controller of passed argument type for _, device := range vmDevices {

Discussion:
vSphere cloud provider volume plugin attach disk limits the number of volumes because of two issues: new SCSI controller is only created when one does not exist. A new controller should be when required and limit not reached. disk will fail when attaching disk to slot 7 on controller. Slot 7 on SCSI controller is reserved and therefore should be skipped. This issue has been brought up in Govmomi library .
Change:
const ( // reconcilerLoopSleepDuration is the amount of time the reconciler loop // waits between successive executions <del> reconcilerLoopSleepDuration time.Duration = 1 * time.Nanosecond </del> <ins> reconcilerLoopSleepDuration = 1 * time.Nanosecond </ins> // waitForAttachTimeout is the maximum amount of time a // operationexecutor.Mount call will wait for a volume to be attached. <del> waitForAttachTimeout         time.Duration     = 1 * time.Second nodeName                     k8stypes.NodeName = k8stypes.NodeName("mynodename") kubeletPodsDir               string            = "fake-dir" testOperationBackOffDuration time.Duration     = 100 * time.Millisecond reconcilerSyncWaitDuration   time.Duration     = 10 * time.Second </del> <ins> waitForAttachTimeout         = 1 * time.Second nodeName                     = k8stypes.NodeName("mynodename") kubeletPodsDir               = "fake-dir" testOperationBackOffDuration = 100 * time.Millisecond reconcilerSyncWaitDuration   = 10 * time.Second </ins> ) func hasAddedPods() bool { return true }

Discussion:
Which jobs are flaking: Which test(s) are flaking: periodic-kubernetes-bazel-test-master (xref ) Testgrid link: Reason for failure: Anything else we need to know: to reproduce with : /sig storage
/assign
solved at
still flaking - /reopen
Reopened this issue. <detailsIn response to : still flaking - 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
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
-- No recent failures in the past 2 weeks, are you okay if we close this?
yeah, looks like resolved it /close
Closing this issue. <detailsIn response to : yeah, looks like resolved it Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
it's back not sure if related to this issue but same test with a data race spotted last night looking into filed
Change:
}) } <del> // newHealthzAndMetricsHandler creates a healthz server from the config, and will also </del> <ins> // newHealthEndpointsAndMetricsHandler creates an API health server from the config, and will also </ins> // embed the metrics handler. <del> func newHealthzAndMetricsHandler(config *kubeschedulerconfig.KubeSchedulerConfiguration, informers informers.SharedInformerFactory, isLeader func() bool, checks ...healthz.HealthChecker) http.Handler { </del> <ins> // TODO: healthz check is deprecated, please use livez and readyz instead. Will be removed in the future. func newHealthEndpointsAndMetricsHandler(config *kubeschedulerconfig.KubeSchedulerConfiguration, informers informers.SharedInformerFactory, isLeader func() bool, healthzChecks, readyzChecks []healthz.HealthChecker) http.Handler { </ins> pathRecorderMux := mux.NewPathRecorderMux("kube-scheduler") <del> healthz.InstallHandler(pathRecorderMux, checks...) </del> <ins> healthz.InstallHandler(pathRecorderMux, healthzChecks...) healthz.InstallLivezHandler(pathRecorderMux) healthz.InstallReadyzHandler(pathRecorderMux, readyzChecks...) </ins> installMetricHandler(pathRecorderMux, informers, isLeader) slis.SLIMetricsWithReset{}.Install(pathRecorderMux)

Discussion:
Quoted from 's Splitting healthz/ into livez/ and readyz/
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
/cc
/sig scheduling
I read all the content of the PR comment and am willing to work on this issue Do we need to continue some discussion for this issue
Hi , thanks for offering your help. But I was working in progress before knowing you can work on this. However, please feel free to contribute the similar issue
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale