jiebi/CodeConvo huggingface dataset:
Code change:
) const ( <del> diskPartitionSuffix = "" checkSleepDuration  = time.Second </del> <ins> diskPartitionSuffix     = "" nvmeDiskPartitionSuffix = "p" checkSleepDuration      = time.Second </ins> ) // AWSDiskUtil provides operations for EBS volume.

Related discussion:
text: When using a AWS EBS PV or on-line volume with a partition on a Nitro machine, the volume is available as NVMe device. Kubelet is not able to format & mount the partition: It seems to me that AWS EBS volume plugin does not support partitions at all. The partition is mounted. Using an in-line volume with this pod:
/sig storage /sig cloud-provider /area provider/aws
/triage accepted
Code change:
<-stoppedChan // Simulate what DSOWP does <del> pv.Spec.Capacity[v1.ResourceStorage] = tc.newPVSize volumeSpec = &volume.Spec{PersistentVolume: pv} </del> <ins> pvWithSize.Spec.Capacity[v1.ResourceStorage] = tc.newPVSize volumeSpec = &volume.Spec{PersistentVolume: pvWithSize} </ins> dsw.AddPodToVolume(podName, pod, volumeSpec, volumeSpec.Name(), "" /* volumeGidValue */) // mark volume as resize required asw.MarkFSResizeRequired(volumeName, podName)

Related discussion:
text: <!-- 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 --pull-kubernetes-unit : (PR with no go code changes, should not have failed any unit tests) links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/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
/assigne
/assign
/assign tried to fix it in
Code change:
## Prerequisites This example requires a running Kubernetes cluster and kubectl in the version at least 1.1. <ins> [Heapster](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster as horizontal pod autoscaler uses it to collect metrics (if you followed [getting started on GCE guide](../../../docs/getting-started-guides/gce.md), heapster monitoring will be turned-on by default). </ins> ## Step One: Run & expose php-apache server

Related discussion:
text: The heapster needs to be installed if end user want to use autoscaler feature, we should mention this in document.
Code change:
env.ServiceManagementEndpoint) } <del> return nil, fmt.Errorf("No credentials provided for AAD application %s", config.AADClientID) </del> <ins> return nil, ErrorNoAuth </ins> } // ParseAzureEnvironment returns azure environment by name

Related discussion:
text: Currently there is no way to run without any identity (be it service principal or E/MSI). In reality code running on a worker node can use via - and only via - without the need to access ARM. Here is the proposed change a new mode authN = this mode, is basically telling the cloud provider to work any identity, this means only IMDS calls is allowed. This mode can be detected from if no SPN set and both MSI settings are set to . to use a config map within the cluster. This config map can be loaded on the cluster statically. or created - if not existent - in that then only is used in The net new result of the above is users bootstrapping clusters can configure the worker node to use without any identity on said worker nodes.
/sig azure These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by ‍
In-tree AzureDisk volume plugin is also depending on Azure credential to fetch lun id. we should figure out how to solve it without credential
fetch disk lun id is also a dependency in kubelet code now, after my investigation, it could be removed on Linux node, while it cannot be removed on Windows node, need to change the k/k upstream code, there is a discussion on going here: , let' wait for the discussion result.
For Linux: 1- use IMDS my understanding is new api versions will have the disk/lun pairs. 2- don't use arm for the return of is the second parameter passed to . For Windows: I don't understand the dep on ARM for this. The above still apply, we just need to find a way to encode the value as ut return from that allow us to find the disk by on a windows machine. might be a good source for this. Ideally speaking. The value should be the same. But i will leave it for you to decide.
could be a good idea since currently it's a LUN num returned by Attach() and then it could be changed to the windows disk num, I will make the code change on v1.15 later, thanks for discussion.
Update: PR would remove the VM API calls when getting the LUN number for AzureDisk.
Code change:
return -1, danglingErr } <del> if disk.DiskProperties != nil && disk.DiskProperties.Encryption != nil && disk.DiskProperties.Encryption.DiskEncryptionSetID != nil { diskEncryptionSetID = *disk.DiskProperties.Encryption.DiskEncryptionSetID </del> <ins> if disk.DiskProperties != nil { if disk.DiskProperties.DiskSizeGB != nil && *disk.DiskProperties.DiskSizeGB >= diskCachingLimit && cachingMode != compute.CachingTypesNone { // Disk Caching is not supported for disks 4 TiB and larger // https://docs.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance#disk-caching cachingMode = compute.CachingTypesNone klog.Warningf("size of disk(%s) is %dGB which is bigger than limit(%dGB), set cacheMode as None", diskURI, *disk.DiskProperties.DiskSizeGB, diskCachingLimit) } if disk.DiskProperties.Encryption != nil && disk.DiskProperties.Encryption.DiskEncryptionSetID != nil { diskEncryptionSetID = *disk.DiskProperties.Encryption.DiskEncryptionSetID } </ins> } if v, ok := disk.Tags[WriteAcceleratorEnabled]; ok { if v != nil && strings.EqualFold(*v, "true") { writeAcceleratorEnabled = true

Related discussion:
text: <!-- 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: there is a disk resize scenario: In the beginning, it’s 3TiB with cachingMode=ReadOnly, and then disk detached, resized to 4TiB, then user find they could not attach that disk back to any agent node, I think that’s a bug we need to fix. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
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
Code change:
return nil, err } <del> leaderElectionClient := clientset.NewForConfigOrDie(restclient.AddUserAgent(kubeconfig, "leader-election")) </del> <ins> // shallow copy, do not modify the kubeconfig.Timeout. config := *kubeconfig config.Timeout = s.GenericComponent.LeaderElection.RenewDeadline.Duration leaderElectionClient := clientset.NewForConfigOrDie(restclient.AddUserAgent(&config, "leader-election")) </ins> eventRecorder := createRecorder(client, KubeControllerManagerUserAgent)

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kube-cm kube-scheduler does not exit when kube-apiserver suspended What you expected to happen: kube-cm kube-scheduler should exit after LeaderElector stops leading 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 api-machinery /kind bug
/assign
/cc
Code change:
ginkgo.By("Wait for the node to be ready") waitForNodeReady() <del> for _, customClass := range []*schedulingv1.PriorityClass{customClassA, customClassB, customClassC} { </del> <ins> customClasses := []*schedulingv1.PriorityClass{customClassA, customClassB, customClassC} for _, customClass := range customClasses { </ins> _, err := f.ClientSet.SchedulingV1().PriorityClasses().Create(context.Background(), customClass, metav1.CreateOptions{}) <del> framework.ExpectNoError(err) </del> <ins> if err != nil && !apierrors.IsAlreadyExists(err) { framework.ExpectNoError(err) } </ins> } <ins> gomega.Eventually(func() error { for _, customClass := range customClasses { _, err := f.ClientSet.SchedulingV1().PriorityClasses().Get(context.Background(), customClass.Name, metav1.GetOptions{}) if err != nil { return err } } return nil }, priorityClassesCreateTimeout, pollInterval).Should(gomega.BeNil()) </ins> }) ginkgo.AfterEach(func() {

Related discussion:
text: Flaked a couple of times on serial lane with the same error. Test is relatively new. This run only has the single test flake: /sig node /kind flake /cc
/assign
New recent failures: /triage accepted
Code change:
n.mu.RLock() defer n.mu.RUnlock() value, ok = n.cache[predicateKey][equivalenceHash] <ins> if ok { metrics.EquivalenceCacheHits.Inc() } else { metrics.EquivalenceCacheMisses.Inc() } </ins> return value, ok }

Related discussion:
text: /kind feature The equivalence cache feature is planned to move to beta in 1.11, and it would be useful to have some metrics attached to it. The equivalence cache should improve scheduling throughput, so we want to be able to correlate e.g. throughput with eCache hit rate. /sig scheduling /sig instrumentation
/assign misterikkit
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
Code change:
import ( "context" <ins> "strings" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" utilversion "k8s.io/apimachinery/pkg/util/version" "k8s.io/apiserver/pkg/endpoints/discovery"

Related discussion:
text: <!-- 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: pull-kubernetes-e2e-gce Which test(s) are flaking: Discovery should validate PreferredVersion for each APIGroup Testgrid link: Reason for failure: The test does not handle API groups which are or removed dynamically during the run of the test. Just because an API group is present in at the beginning of the test does not mean or will be present by the end of the test. This is particularly true for the dynamic/custom-resource API groups registered/unregistered during the e2e test run /sig api-machinery /assign
mitigation opened at
Saw this today in It seems to happen relatively often Likely due to the CRD created in: Should the ValidatingAdmissionPolicy test CRD have its group name template changed to match the existing test exclusion for groups ending in /cc
Code change:
mockCadvisor.On("VersionInfo").Return(versionInfo, nil) expectedNode := &api.Node{ <del> ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: testKubeletHostname}, </ins> Spec:       api.NodeSpec{}, Status: api.NodeStatus{ Conditions: []api.NodeCondition{

Related discussion:
text: Looks like some kubelet unit tests perform a lookupIp which ends up depending on the health of the local resolver. Specifically has this failing: Which leads to the test in: And we recently swapped out the node names from testnode to 127.0.0.1, so probably the culprit?
/ref
Interesting. I did swap out the node names in the unit test as part of to be 127.0.0.1, party because I thought that it wouldn't have any problems resolving during unit tests.
/cc
Code change:
mockCadvisor.On("VersionInfo").Return(versionInfo, nil) expectedNode := &api.Node{ <del> ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: testKubeletHostname}, </ins> Spec:       api.NodeSpec{}, Status: api.NodeStatus{ Conditions: []api.NodeCondition{

Related discussion:
text: cc
What is the environment where you are running the tests? They pass for me on my mac, a linux box, and shippable seems to be passing them as well.
I couldn 't reproduce the failure either.
I'm out right now; i'll try them when i get back. For the record, I run hack/test- Paul Morie wrote:
Ahem FTR This acronym is going to go quad-plat Paul Morie wrote:
I ran on both platforms and saw the tests pass.
I'm still seeing it. Won't have bandwidth to dig in personally until tomorrow.
seeing a similar failure after a git pull
I knew I wasn't crazy
environment: fedora 21, golang: 1.4, docker: 1.6
I think I see the problem. When I set the node name to in the test I was assuming it would parse as a valid ip address and not end up at the LookupIP call. But only the node name (and not the kubelet hostname) is being set (except in my new test where I ) so it's trying to do a lookup. Do you think you could test just changing the default hostname from "testnode" to "127.0.0.1" and see if that fixes it for you?
Trying now
I still get failures but no panic / threaddump.
gist coming
this looks like again?
Good that it isn't panicing any longer. I can dig into the test failures tomorrow (I think it should be relatively simple to resolve).
cool, thanks for looking
Passes in master now for me. Closing.
FYI, they will break again once goes in, and then we can merge my PR to see if that fixes it for you.
:+1:
is in -- are these tests breaking again?
I just rebased which I think will fix them.
They are breaking again.
is on it.
Code change:
func TestVersion(t *testing.T) { fakeRuntime, endpoint := createAndStartFakeRemoteRuntime(t) <del> defer fakeRuntime.Stop() </del> <ins> defer func() { fakeRuntime.Stop() // clear endpoint file if addr, _, err := util.GetAddressAndDialer(endpoint); err == nil { if _, err := os.Stat(addr); err == nil { os.Remove(addr) } } }() </ins> r := createRemoteRuntimeService(endpoint, t) version, err := r.Version(apitest.FakeVersion)

Related discussion:
text: Which jobs are flaking: periodics-kubernetes-bazel-test Which test(s) are flaking: //pkg/kubelet/cri/remote TestVersion Testgrid link: Reason for failure: Error: Received unexpected error: rpc error: code = Unavailable desc = transport is closing panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference Anything else we need to know: To reproduce with stress: go test -race -c ./pkg/kubelet/cri/remote stress - TestVersion Detailed logs
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 testing
I 'll give it a see and fix it :)
/assign
/remove-sig testing SIG node owns their unit tests. SIG testing owns the framework, infrastructure, etc.
/sig node
Code change:
"testing" "time" <ins> dto "github.com/prometheus/client_model/go" </ins> "github.com/stretchr/testify/assert" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/clock" "k8s.io/apimachinery/pkg/util/diff" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" <ins> "k8s.io/kubernetes/pkg/kubelet/metrics" </ins> ) const (

Related discussion:
text: Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign
Code change:
if config.EnableContentionProfiling { goruntime.SetBlockProfileRate(1) } <ins> routes.DebugFlags{}.Install(pathRecorderMux, "v", routes.StringFlagPutHandler(logs.GlogSetter)) </ins> } return pathRecorderMux }

Related discussion:
text: What would you like to be : Support dynamically set log level for kube-scheduler, is blocked on node controller approval, but we can move forward with a scheduler only change. /sig scheduling
/help
/assign /remove-help
do you have a PR for this one?
I submitted the PR.
Code change:
"k8s.io/client-go/restmapper" "k8s.io/component-base/featuregate" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> "k8s.io/component-base/metrics/legacyregistry" </ins> "k8s.io/klog/v2" "k8s.io/kubernetes/test/integration/framework" testutils "k8s.io/kubernetes/test/utils"

Related discussion:
text: In the new scheduler performance testing framework, (bool) is provided to benchmark performance of pods created in an "operator": (L11 below) However, the initialized Pods created in L5~L7 seem to be also benchmarked, although it doesn't specify . (please see the reproduce steps below). I think it's b/c once scheduler starts, the associated Prometheus artifacts are also up, and it's a single in-memory datastore. So no matter we start to collect the metric in which step, the prometheus data is already up-to-date. In the above workload config, the final data have benchmarked 1500 pods instead of 1000 pods. I guess it won't work either if running in the pod initialization step or not. Unless we manage a breakpoint at the end of each step, and calculate delta histogram for the step that specifies . Pods created in step without are not benchmarked. Apply the following diff: And then run: You will get an output sth. like: /sig scheduling
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
Could you please help confirm if it's an issue?
cc
Unfortunately, does not apply for metrics gathered from . As you mentioned. The default gatherer collects all metrics produced by the scheduler. It's the scheduler itself who knows pod specs and would have to decide which pods will get ignored when updating metrics. The question is if computing metrics for a subset of pods processed by the scheduler is a valid use case.
This is probably what we want. Is something like that possible ?
I think being able to absolutely ignore certain pods for metrics is an overkill.
The use case is to ignore the pods created in steps that don't specify , so as to collect the Pod metrics create at particular step(s) (). Otherwise, the semantics of option is quite misleading. Nope, that's not the intention. We don't need to target certain pods, like using label selector or whatever. Just as I mentioned, measure pods created at particular steps.
Code change:
"k8s.io/client-go/restmapper" "k8s.io/component-base/featuregate" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> "k8s.io/component-base/metrics/legacyregistry" </ins> "k8s.io/klog/v2" "k8s.io/kubernetes/test/integration/framework" testutils "k8s.io/kubernetes/test/utils"

Related discussion:
text: I would do something like the following: if a step has collectMetrics:false, we wait for them to finish scheduling, and then we take a snapshot of the histogram. Then for the next step that has collectMetrics:true, we take the diff with the latest snapshot to report the results. This might not be perfect, as we don't control if the metrics have finished syncing when we take the snapshot. But I think that's fine. Would doing this be possible? Now, if we have steps that run in parallel, one with collectMetrics:false and another with collectMetrics:true, then this doesn't work. Note that I don't know the details of how the gatherer works.
That adheres to what I have in my mind - we can only manage this on client side. I think it's fine. As we are already fetching the "snapshot" when pods get scheduled when equals true. True. An alternative is to design the case to be like: the step with to employ Pods that are all unschedulable, and then specify a custom metric "schedulere2eschedulingdurationseconds[result="unschedulable"]" to target a particular histogram instead of all histograms (default option) inside a histogramVec. Note this can only be possible when and some subsequent changes get in place.
We might just call Histogram.Clear() method which will clear what has been collected so far at the end of phase: Assuming individual phases have no pods in common and each phase can clear metrics without affecting other phases. Though, as said, it will work only for serial case.
WDYT
I'm afraid doesn't work. That was my initial thought as well, but no luck. I guess it's b/c, theoretically, we cannot reset a metric on the server side - Promoetheus' model doesn't support this. But let me know if I miss anything.
The performance tests assume all the metrics all gathered and accessed in the same binary. As long as that's the case, works.
Code change:
"k8s.io/client-go/restmapper" "k8s.io/component-base/featuregate" featuregatetesting "k8s.io/component-base/featuregate/testing" <ins> "k8s.io/component-base/metrics/legacyregistry" </ins> "k8s.io/klog/v2" "k8s.io/kubernetes/test/integration/framework" testutils "k8s.io/kubernetes/test/utils"

Related discussion:
text: We already call in the code:
That was my understanding as well, but no luck :( Here is a diff to call in case when "concreteOp.CollectMetrics" is false: <details<summaryDiff:</summary<p</p</detailsAnd below is the output - it's still 1500 (500 init pods plus 1000 measured pods) instead of 1000 being benchmarked: <details<summaryOutput:</summary<p</p</details
Also, if you run the tests and together, the result proves doesn't work as expected:
But I do find a way to fix this: .