jiebi/CodeConvo huggingface dataset:
Change:
influxdb "github.com/influxdata/influxdb/client" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/kubernetes/pkg/client/clientset_generated/clientset" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
The following E2E test is failing in the GCE 1.5-1.6 upgrade jobs. Please take a look and let me know ASAP if this is a 1.6 blocker or not (I think it may be a flake, but need you to confirm). https://k8s- Expected error: <*errors.errorString | 0xc421d5ef10: { s: "expected to find one replica for RC or deployment with label heapster but got 0", } expected to find one replica for RC or deployment with label heapster but got 0 not to have occurred
/assign
can you help get this looked at and triaged ASAP? Thanks.
I pinged by email. He's really the one who should look at this.
The problem seems to be not with the test itself but with Kubernetes or test framework, since the test failed on starting Heapster. I'll investigate more later today.
I haven't got time to investigate. This seems to be unrelated to monitoring itself, so any help during MTV day would be great. If not I'll try to fix this tomorrow
thanks
The problem is in , in function . The function is called immediately from , w/o waiting for system pods (heapster) to start. We should give some time for heapster to become ready, as it takes few minutes after cluster creation.
CC
thanks a lot for investigation! is going to fix it.
Change:
"k8s.io/kubernetes/federation/apis/federation" "k8s.io/kubernetes/federation/client/clientset_generated/federation_release_1_3" "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/errors" </ins> "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_3" "k8s.io/kubernetes/pkg/client/restclient"

Discussion:
Federated service shards are created only in the clusters that have the specified namespace. To fix this problem we need to create the namespace on-demand while creating the federated service shards. cc
As discussed, we explicitly decided not to do it this way. In Kubernetes, when one creates an entity, if the namespace does not exist, the creation call fails. What we need to do for v1.3 is pre-create the test namespace in all of the underlying clusters as part of the e2e test turnup.
Change:
configv1beta3 "k8s.io/kubernetes/pkg/scheduler/apis/config/v1beta3" ) <del> func loadConfigFromFile(logger klog.Logger, file string) (*config.KubeSchedulerConfiguration, error) { </del> <ins> // LoadConfigFromFile loads scheduler config from the specified file path func LoadConfigFromFile(logger klog.Logger, file string) (*config.KubeSchedulerConfiguration, error) { </ins> data, err := os.ReadFile(file) if err != nil { return nil, err

Discussion:
I want to be exported as a public function imports scheduler code and runs scheduler simulations for pods to decide which nodegroup should be scaled up. consider this case: a user is running a scheduler with custom scheduler config the user wants cluster-autoscaler to run scheduler simulations based on the custom scheduler config For ii default scheduler config is used in cluster-autoscaler scheduler simulations. Right now, it is not possible to use custom scheduler config for cluster-autoscaler scheduler simulations but I am working on a PR () to support this feature. For this feature, I need to parse scheduler config. . It would help if we can have exported as (just like ) so that programs which need to parse scheduler config can use the exported function directly instead of writing custom code.
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
PR:
/assign vadasambar
wdyt?
/sig autoscaling
LGTM, thanks.
Change:
Buckets:   buckets, } vec := metrics.NewHistogramVec(HistogramOpts, labels) <del> registerMetrics.Do(func() { legacyregistry.MustRegister(vec) }) </del> <ins> // Use local registry var registry = metrics.NewKubeRegistry() var gather metrics.Gatherer = registry registry.MustRegister(vec) </ins> // Observe two metrics with same value for label1 but different value of label2. vec.WithLabelValues("value1-0", "value2-0").Observe(1.5) vec.WithLabelValues("value1-0", "value2-1").Observe(2.5) vec.WithLabelValues("value1-1", "value2-0").Observe(3.5) vec.WithLabelValues("value1-1", "value2-1").Observe(4.5) metricName := fmt.Sprintf("%s_%s_%s", HistogramOpts.Namespace, HistogramOpts.Subsystem, HistogramOpts.Name) <del> histogramVec, _ := GetHistogramVecFromGatherer(legacyregistry.DefaultGatherer, metricName, tt.lvMap) </del> <ins> histogramVec, _ := GetHistogramVecFromGatherer(gather, metricName, tt.lvMap) </ins> if diff := cmp.Diff(tt.wantVec, histogramVec); diff != "" { t.Errorf("Got unexpected HistogramVec (-want +got):n%s", diff) }

Discussion:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument 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 instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in
Change:
var _ = ginkgo.Describe("[sig-api-machinery] Events", func() { f := framework.NewDefaultFramework("events") <del> ginkgo.It("should ensure that an event can be fetched, patched, deleted, and listed", func() { </del> <ins> /* Release : v1.19 Testname: Event resource lifecycle Description: Create an event, the event MUST exist. The event is patched with a new message, the check MUST have the update message. The event is deleted and MUST NOT show up when listing all events. */ framework.ConformanceIt("should ensure that an event can be fetched, patched, deleted, and listed", func() { </ins> eventTestName := "event-test" ginkgo.By("creating a test event")

Discussion:
This issue proposes the writing of a new test for the API endponts , , , , , and with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these query results from APIsnoop, we are lacking in tests for the following endpoints related to Events We chose the following 5 endpoints for this mock test: - - - Test outline: Event in namespace default with custom fields all events in all namespaces find event created in in response of the content of the event created in events by name in namespace default ensure that the event updated from event by name all events in namespace ensure event in namespace default was deleted This mock test uses client-go's standard functions for talking to the Event area of the API. Discover useragents Display endpoints hit by the test Show the change in coverage after the mock test If a test with these calls gets merged in, conformance will go up by 5 endpoints. /sig architecture /area conformance
lgtm according to the SIG-Arch conformance office hours 17th December 2019.
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
/reopen can you put the checkboxes at the top for your apisnoop org pr, the test, and link to the promotion PR? I think we are ready.
/open
Reopened this issue. <detailsIn response to : /reopen can you put the checkboxes at the top for your apisnoop org pr, the test, and link to the promotion PR? I think we are ready. 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
/retitle Promote CoreV1Event test - +5 coverage
/assign
This test was written before the tickets were stored in APISnoop branches. Unsure what to do with it in regards to the APISnoop PR
Change:
id: monitoring-heapster port: 80 containerPort: 8082 <ins> labels: name: heapster kubernetes.io/cluster-service: "true" </ins> selector: name: heapster

Discussion:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.
Change:
q.AddUnschedulableIfNotPresent(q.newPodInfo(&unschedulablePod), q.SchedulingCycle()) q.AddUnschedulableIfNotPresent(q.newPodInfo(&highPriorityPod), q.SchedulingCycle()) q.MoveAllToActiveOrBackoffQueue("test") <ins> q.lock.RLock() defer q.lock.RUnlock() </ins> if q.activeQ.Len() != 1 { t.Error("Expected 1 item to be in activeQ") }

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: pull-kubernetes-bazel-test Which test(s) are flaking: pkg/scheduler/internal/queue Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /assign
I just sent a pr for it according to the error message, but I'm not very sure if it will make things all right.
/assign
Change:
var u map[string]interface{} var err error if unstr, ok := obj.(Unstructured); ok { <del> // UnstructuredContent() mutates the object so we need to make a copy first u = unstr.DeepCopyObject().(Unstructured).UnstructuredContent() </del> <ins> u = unstr.UnstructuredContent() </ins> } else { t := reflect.TypeOf(obj) value := reflect.ValueOf(obj)

Discussion:
What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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
Change:
), }, expected: &DeviceRunContainerOptions{ <del> Annotations: []kubecontainer.Annotation{ {Name: "cdi.k8s.io/devicemanager_pod-container", Value: "vendor1.com/class1=device1,vendor2.com/class2=device2,vendor3.com/class3=device3,vendor4.com/class4=device4"}, }, </del> CDIDevices: []kubecontainer.CDIDevice{ {Name: "vendor1.com/class1=device1"}, {Name: "vendor2.com/class2=device2"},

Discussion:
Kubelet should stop using annotations to pass CDI device IDs to CRI runtimes. CDIDevices CRI field should be used for this purpose. This should be done when Kubelet that doesn't support CRI field reaches EOL and two major CRI runtimes support CRI field. Here is a PR comment that gives more details about this: Kubelet started using CDIDevices CRI field in . Previous version 1.27 will reach EOL .CRI-O started using it in . Previous version 1.27 will reach EOL together with Kubernetes 1.27.Containerd started using it in . Version 1.7 will reach EOL in a 6 months after Containerd 2.0 release Previous version 1.6 doesn't support CDI injections and should not be considered. So, safer option would be to wait until Containerd 1.7 reaches EOL. However it's relatively safe to do it earlier when 1.7.0 and 1.7.1 have little chances to be in real use. Containerd v1.7.0 and v1.7.1 is not used by the Linux distributions from , so it's safe to remove annotations support from the Kubelet in 1.31 in my opinion.
/sig node
/triage accepted /priority important-longterm
/assign
Change:
if err != nil { return err } <del> if condition := findConditionByType(patchedStatus.Status.Conditions, customConditionType); condition != nil { </del> <ins> if condition := findConditionByType(statusToUpdate.Status.Conditions, customConditionType); condition != nil { </ins> condition.LastTransitionTime = now2 } else { framework.Failf("patched object does not have the required condition %v", customConditionType)

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig apps
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 suspecting as cause
Ack, indeed, because this is the suite for alpha features enabled. We have this fix ready for the test itself: /cc
/cc It flakes in
/retitle [Flaking Test] [Conformance] [sig-apps] Job should apply changes to a job status
It used to fail with errors like After it fails with : [FAILED] patched object should have the applied condition with LastTransitionTime time.Date(2024, time.March, 7, 17, 58, 34, 0, time.UTC), got time.Date(2024, time.March, 7, 17, 58, 33, 0, time.Local) instead In [It] at: @ 03/07/24 17:58:34.109 Here I open the follow up fix: PTAL.
Change:
pv.Status.Phase = v1.VolumeBound // bind pvc to "pv-$i" <del> // pvc.Spec.VolumeName = pv.Name </del> pvc.Status.Phase = v1.ClaimBound } else { pv.Status.Phase = v1.VolumeAvailable } <del> if err := CreatePersistentVolumeWithRetries(client, pv); err != nil { </del> <ins> // Create PVC first as it's referenced by the PV when the `bindVolume` is true. if err := CreatePersistentVolumeClaimWithRetries(client, namespace, pvc); err != nil { </ins> lock.Lock() defer lock.Unlock() <del> createError = fmt.Errorf("error creating PV: %s", err) </del> <ins> createError = fmt.Errorf("error creating PVC: %s", err) </ins> return } // We need to update statuses separately, as creating pv/pvc resets status to the default one. <del> if _, err := client.CoreV1().PersistentVolumes().UpdateStatus(context.TODO(), pv, metav1.UpdateOptions{}); err != nil { </del> <ins> if _, err := client.CoreV1().PersistentVolumeClaims(namespace).UpdateStatus(context.TODO(), pvc, metav1.UpdateOptions{}); err != nil { </ins> lock.Lock() defer lock.Unlock() <del> createError = fmt.Errorf("error updating PV status: %s", err) </del> <ins> createError = fmt.Errorf("error updating PVC status: %s", err) </ins> return } <del> if err := CreatePersistentVolumeClaimWithRetries(client, namespace, pvc); err != nil { </del> <ins> if err := CreatePersistentVolumeWithRetries(client, pv); err != nil { </ins> lock.Lock() defer lock.Unlock() <del> createError = fmt.Errorf("error creating PVC: %s", err) </del> <ins> createError = fmt.Errorf("error creating PV: %s", err) </ins> return } <del> if _, err := client.CoreV1().PersistentVolumeClaims(namespace).UpdateStatus(context.TODO(), pvc, metav1.UpdateOptions{}); err != nil { </del> <ins> // We need to update statuses separately, as creating pv/pvc resets status to the default one. if _, err := client.CoreV1().PersistentVolumes().UpdateStatus(context.TODO(), pv, metav1.UpdateOptions{}); err != nil { </ins> lock.Lock() defer lock.Unlock() <del> createError = fmt.Errorf("error updating PVC status: %s", err) </del> <ins> createError = fmt.Errorf("error updating PV status: %s", err) </ins> return }

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: Run integration test , for the case which needs PV or PVC, got the error which info us that PVC is not found, Furtherly, this will lead a inconsistent PV / PVC status, and fail the whole testcase. What you expected to happen: Run successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The error message is thrown here, Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig scheduling /sig testing
/assign
/triage accepted
Change:
return false } <del> if s.AnyOf == nil { s.AnyOf = []NestedValueValidation{ </del> <ins> if s.ValueValidation == nil { s.ValueValidation = &ValueValidation{} } if s.ValueValidation.AnyOf == nil { s.ValueValidation.AnyOf = []NestedValueValidation{ </ins> {ForbiddenGenerics: Generic{Type: "integer"}}, {ForbiddenGenerics: Generic{Type: "string"}}, } } else { <del> s.AllOf = append([]NestedValueValidation{ </del> <ins> s.ValueValidation.AllOf = append([]NestedValueValidation{ </ins> { ValueValidation: ValueValidation{ AnyOf: []NestedValueValidation{

Discussion:
What happened: API server panics handling requests for a CRD with OpenAPI validation with What you expected to happen: CRD is applied successfully. How to reproduce it (as minimally and precisely as possible): kind create cluster --image kindest/node:v1.16.1 then kubectl apply: Partial logs from API server: Anything else we need to know?: Environment: Kind Kubernetes version (use ):OS (e.g: ):
/sig api-machinery
/cc
where It seems that s.AnyOf was referencing some invalid address.
yes, which is very strange, given s was dereferenced earlier in the same method: is investigating
reproduced and has a fix
I had the same issue with prometheus (kube 1.16.1). Deploying is fine but when trying to delete, it crashes the api server. For those who can't upgrade to 1.16.2+ (fixed version) there is a workaround : using etcd to delete the resources that crash the api server : here I grep on coreos because I know it is prometheus that crashes the api server Remove every item in the list that causes the crash :
Note this is also resolved in 1.15.5+ and 1.16.2+, upgrading to 1.17.x is not required to resolve this
Change:
// Kill any running node processes cleanupNodeProcesses(host) <del> testArgs, err := updateOSSpecificKubeletFlags(testArgs, host, workspace) </del> <ins> testArgs, err := osSpecificActions(testArgs, host, workspace) </ins> if err != nil { return "", err }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: pull-kubernetes-node-crio-e2e Which test(s) are failing: N/A Since when has it been failing: N/A Testgrid link: Reason for failure: Anything else we need to know:
/sig node
/assign
Change:
Expect(err).NotTo(HaveOccurred()) if defaultStr == "" { <del> delete(sc.Annotations, storageutil.IsDefaultStorageClassAnnotation) </del> <ins> delete(sc.Annotations, storageutil.BetaIsDefaultStorageClassAnnotation) </ins> } else { if sc.Annotations == nil { sc.Annotations = make(map[string]string) } <del> sc.Annotations[storageutil.IsDefaultStorageClassAnnotation] = defaultStr </del> <ins> sc.Annotations[storageutil.BetaIsDefaultStorageClassAnnotation] = defaultStr </ins> } sc, err = c.StorageV1().StorageClasses().Update(sc)

Discussion:
https://k8s- Failed: [] Dynamic provisioning [] DynamicProvisioner Default should be disabled by removing the default annotation[Slow] [Serial] [Disruptive] [Volume] {Kubernetes e2e suite} Failed: [] Dynamic provisioning [] DynamicProvisioner Default should be disabled by changing the default annotation[Slow] [Serial] [Disruptive] [Volume] {Kubernetes e2e suite}
These test have failed in the last few serial jobs () and may represent a regression. The tests were in by Assigning her to take a look. /assign cc:
CC
The e2e test is using IsDefaultStorageClassAnnotation, which used to equal the beta annotation, but then got changed to use the non-beta annotation. However, the default storage classes that are installed are using the beta annotation. So when the test tries to disable the default storage class by modifying or deleting the annotation, it is trying to use the non-beta annotation which does not exist, so it has no affect, since the the beta annotation is unchanged. So for now, the simple fix should be to make the test modify the beta annotation. I am working on it now and should have a PR out soon. Longer term, the test should be able to detect which annotation is being used and modify the appropriate one.
Looks like this is failing again with a different error: https://k8s-
This should be fixed by
Good to know, I'll leave open until we confirm in e2e
this test went green in the last two e2e's