jiebi/CodeConvo huggingface dataset:
Change:
What happened: When the standalone (or VMAS) instance backing a registered node is removed (from Azure, ie. the instance is deleted), that node will remain forever due to the Azure cloud provider only checking whether the node was removed from a containing VMSS. Moreover this will triggers frequent VMSS full re-scans (when the instance name conforms to the expected VMSS instances name format, as we cache miss on every call), hammering Azure's VMSS List API, and causing throttling. A VMAS/standalone node leaving a cluster would cause controller-manager to log that error (here on k8s v1.18.2): What you expected to happen: The cloud provider should answer CM node lifecycle controller that the VM instance went missing and the node can be garbage collected. How to reproduce it (as minimally and precisely as possible): 1- Create a non-VMSS Azure node 2- Configure it to register to an Azure k8s cluster 3- Delete that node's instance from Azure console Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.2 Cloud provider or hardware configuration: Azure, controller-manager running with and OS (e.g: ): Ubuntu 20.04 LTS Kernel (e.g. ): Linux 5.4.0-1010-azure Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure

Discussion:
// GetPowerStatusByNodeName returns the power state of the specified node. func (ss *scaleSet) GetPowerStatusByNodeName(name string) (powerState string, err error) { <ins> managedByAS, err := ss.isNodeManagedByAvailabilitySet(name, azcache.CacheReadTypeUnsafe) if err != nil { klog.Errorf("Failed to check isNodeManagedByAvailabilitySet: %v", err) return "", err } if managedByAS { // vm is managed by availability set. return ss.availabilitySet.GetPowerStatusByNodeName(name) } </ins> _, _, vm, err := ss.getVmssVM(name, azcache.CacheReadTypeDefault) if err != nil { return powerState, err

} mockVMSSVMClient.EXPECT().List(gomock.Any(), ss.ResourceGroup, testVMSSName, gomock.Any()).Return(expectedVMSSVMs, nil).AnyTimes() <ins> mockVMsClient := ss.cloud.VirtualMachinesClient.(*mockvmclient.MockInterface) mockVMsClient.EXPECT().List(gomock.Any(), gomock.Any()).Return([]compute.VirtualMachine{}, nil).AnyTimes() </ins> powerState, err := ss.GetPowerStatusByNodeName("vmss-vm-000001") assert.Equal(t, test.expectedErr, err, test.description+", but an error occurs") assert.Equal(t, test.expectedPowerState, powerState, test.description)
Change:
Which jobs are failing: Which test(s) are failing: Test Overall [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is force deleted while kubelet is down [Disruptive][Slow][LinuxOnly] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow][LinuxOnly] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority critical-urgent /sig testing /sig storage
This looks like an infrastructure issue but pinging just in case anyone has immediate insight
/remove-kind bug
Looks like recent changes here: /cc
/assign
/reopen unfortunately I don't resolved the issues
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
/assign
how do you say that ? looking at grid - it looks like it is not breaking anymore? Same result with filter applied - There is one failed run after my fix merged - but that is unrelated to original PR and appears to be because of broken cluster: Did I miss anything?
apologies, I believe your fix solved its intended issue, but the job is still failing. I was not clear about that in my comment :+1:
Should this be closed - ? I do not see these tests flaking anymore.
/remove-sig testing /close
Closing this issue. <detailsIn response to : /remove-sig testing /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
Dashboards are green. Wasn't SIG testing

Discussion:
PodDeleteTimeout = 5 * time.Minute ) <del> // DeletePodOrFail deletes the pod of the specified namespace and name. </del> <ins> // DeletePodOrFail deletes the pod of the specified namespace and name. Resilient to the pod // not existing. </ins> func DeletePodOrFail(c clientset.Interface, ns, name string) { ginkgo.By(fmt.Sprintf("Deleting pod %s in namespace %s", name, ns)) err := c.CoreV1().Pods(ns).Delete(context.TODO(), name, metav1.DeleteOptions{}) <ins> if err != nil && apierrors.IsNotFound(err) { return } </ins> expectNoError(err, "failed to delete pod %s in namespace %s", name, ns) }
Change:
What happened: An extra scheduling attempt is observed in some scenarios when kube-scheduler already has already assumed a pod and this has entered the binding routine. If, during this time, a pod update is received, the pod is back to the scheduling queue, even if binding succeeds. This is the correct behavior, as scheduling conditions might change. However this updates could just be unrelated status updates, such as updates to pod conditions. We observe an extra scheduling attempt, which is visible in the log line: Which indicates that an attempt was made when the pod was already scheduled. What you expected to happen: No extra scheduling attempts How to reproduce it (as minimally and precisely as possible): This depends on other controllers running on the cluster that might report pod conditions. One such controller is
/sig scheduling

Discussion:
"reflect" "k8s.io/klog/v2" <del> "k8s.io/kubernetes/pkg/scheduler/profile" </del> v1 "k8s.io/api/core/v1" storagev1 "k8s.io/api/storage/v1"

"k8s.io/client-go/tools/cache" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/scheduler/internal/queue" <ins> "k8s.io/kubernetes/pkg/scheduler/profile" </ins> ) func (sched *Scheduler) onPvAdd(obj interface{}) {

// skipPodUpdate checks whether the specified pod update should be ignored. // This function will return true if //   - The pod has already been assumed, AND <del> //   - The pod has only its ResourceVersion, Spec.NodeName, Annotations, ManagedFields and/or Finalizers //     updated. </del> <ins> //   - The pod has only its ResourceVersion, Spec.NodeName, Annotations, //     ManagedFields, Finalizers and/or Conditions updated. </ins> func (sched *Scheduler) skipPodUpdate(pod *v1.Pod) bool { // Non-assumed pods should never be skipped. isAssumed, err := sched.SchedulerCache.IsAssumedPod(pod)

// Same as above, when annotations are modified with ServerSideApply, // ManagedFields may also change and must be excluded p.ManagedFields = nil <del> // Finalizers must be excluded because scheduled result can not be affected </del> <ins> // The following might be changed by external controllers, but they don't // affect scheduling decisions. </ins> p.Finalizers = nil <ins> p.Status.Conditions = nil </ins> return p } assumedPodCopy, podCopy := f(assumedPod), f(pod)

}, expected: true, }, <ins> { name: "with changes on Conditions", pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "pod-0", }, Status: v1.PodStatus{ Conditions: []v1.PodCondition{ {Type: "foo"}, }, }, }, isAssumedPodFunc: func(*v1.Pod) bool { return true }, getPodFunc: func(*v1.Pod) *v1.Pod { return &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "pod-0", }, } }, expected: true, }, </ins> } { t.Run(test.name, func(t *testing.T) { c := &Scheduler{
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : show a clearer message that better informs the user of a potential conflict between changes done declaratively vs imperatively on the same object, inform whether the changes have been applied, what may have been overwritten based on closed issue resource that has been directly modified imperatively (for example via a kubectl edit command) try to update it again declaratively (for example by kubectl apply -f yamlfile) The following confusing info message appears: "Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply... " Why is this needed: the error message is confusing. is it really an error message or just an informative message? Did the command successfully execute the changes being asked? Were the changes applied successfully? Was there anything overwritten? If changes were successfully applied, what is the reason for this message to show?
/sig cli
background references: and
/assign
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
Agree that this is a confusing message. Could probably use some love. First-round search indexing brought me here.

Discussion:
# Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap`)) <del> warningNoLastAppliedConfigAnnotation = "Warning: %[1]s apply should be used on resource created by either %[1]s create --save-config or %[1]s applyn" </del> <ins> warningNoLastAppliedConfigAnnotation = "Warning: resource %[1]s is missing the %[2]s annotation which is required by %[3]s apply. %[3]s apply should only be used on resources created declaratively by either %[3]s create --save-config or %[3]s apply. The missing annotation will be patched automatically.n" </ins> ) // NewApplyOptions creates new ApplyOptions for the `apply` command

metadata, _ := meta.Accessor(info.Object) annotationMap := metadata.GetAnnotations() if _, ok := annotationMap[corev1.LastAppliedConfigAnnotation]; !ok { <del> fmt.Fprintf(o.ErrOut, warningNoLastAppliedConfigAnnotation, o.cmdBaseName) </del> <ins> fmt.Fprintf(o.ErrOut, warningNoLastAppliedConfigAnnotation, info.ObjectName(), corev1.LastAppliedConfigAnnotation, o.cmdBaseName) </ins> } patcher, err := newPatcher(o, info, helper)

// uses the name from the file, not the response expectRC := "replicationcontroller/" + nameRC + "n" <del> expectWarning := fmt.Sprintf(warningNoLastAppliedConfigAnnotation, "kubectl") </del> <ins> expectWarning := fmt.Sprintf(warningNoLastAppliedConfigAnnotation, "replicationcontrollers/test-rc", corev1.LastAppliedConfigAnnotation, "kubectl") </ins> if errBuf.String() != expectWarning { t.Fatalf("unexpected non-warning: %snexpected: %s", errBuf.String(), expectWarning) }
Change:
What would you like to be : The 'Successfully pulled image' event should contain the duration for image pulling. Why is this needed: Currently the success event is in this form: User has to trace back to the corresponding event for the beginning of image pulling and calculate the duration him/herself:
/sig node /assign

Discussion:
import ( "fmt" <ins> "time" </ins> dockerref "github.com/docker/distribution/reference" v1 "k8s.io/api/core/v1"

return "", msg, ErrImagePullBackOff } m.logIt(ref, v1.EventTypeNormal, events.PullingImage, logPrefix, fmt.Sprintf("Pulling image %q", container.Image), klog.Info) <ins> startTime := time.Now() </ins> pullChan := make(chan pullResult) m.puller.pullImage(spec, pullSecrets, pullChan, podSandboxConfig) imagePullResult := <-pullChan

return "", imagePullResult.err.Error(), ErrImagePull } <del> m.logIt(ref, v1.EventTypeNormal, events.PulledImage, logPrefix, fmt.Sprintf("Successfully pulled image %q", container.Image), klog.Info) </del> <ins> m.logIt(ref, v1.EventTypeNormal, events.PulledImage, logPrefix, fmt.Sprintf("Successfully pulled image %q in %v", container.Image, time.Since(startTime)), klog.Info) </ins> m.backOff.GC() return imagePullResult.imageRef, "", nil }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: aks-engine-azure-windows-master-containerd-serial-slow Which test(s) are failing: [sig-windows] [Feature:Windows] Kubelet-Stats [Serial] Kubelet stats collection for Windows nodes when running 10 pods should return within 10 seconds Since when has it been failing: Unknown. Testgrid link: Reason for failure: The test spawns 10 pods with the same pod name, which contains multiple containers with the same container name. Because of this, the test fails. Logs: Anything else we need to know:
/sig windows These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍

Discussion:
import ( "context" <ins> "fmt" </ins> "time" v1 "k8s.io/api/core/v1"

podName := "statscollectiontest-" + string(uuid.NewUUID()) pod := v1.Pod{ ObjectMeta: metav1.ObjectMeta{ <del> Name: podName, </del> <ins> Name: fmt.Sprintf("%s-%d", podName, i), </ins> Labels: map[string]string{ "name":    podName, "testapp": "stats-collection",

Containers: []v1.Container{ { Image: image.GetE2EImage(), <del> Name:  podName, </del> <ins> Name:  "stat-container", </ins> Command: []string{ "powershell.exe", "-Command",

InitContainers: []v1.Container{ { Image: image.GetE2EImage(), <del> Name:  podName, </del> <ins> Name:  "init-container", </ins> Command: []string{ "powershell.exe", "-Command",
Change:
<!-- 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: if I figure out --timeout,but the timeout is fixed in source not customized the timeout 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:
/assign
/sig cli

Discussion:
kubectl scale --replicas=3 statefulset/web`)) ) <del> const ( timeout = 5 * time.Minute ) </del> type ScaleOptions struct { FilenameOptions resource.FilenameOptions RecordFlags     *genericclioptions.RecordFlags

var waitForReplicas *scale.RetryParams if o.Timeout != 0 && o.dryRunStrategy == cmdutil.DryRunNone { <del> waitForReplicas = scale.NewRetryParams(1*time.Second, timeout) </del> <ins> waitForReplicas = scale.NewRetryParams(1*time.Second, o.Timeout) </ins> } counter := 0
Change:
<!-- 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: the hpa name is always info.Namenot --name 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:
/assign
/sig cli

Discussion:
dryRunStrategy   cmdutil.DryRunStrategy dryRunVerifier   *resource.DryRunVerifier builder          *resource.Builder <del> generatorFunc    func(string, *meta.RESTMapping) (generate.StructuredGenerator, error) </del> <ins> generatorFunc    func(name, refName string, mapping *meta.RESTMapping) (generate.StructuredGenerator, error) </ins> fieldManager     string HPAClient         autoscalingv1client.HorizontalPodAutoscalersGetter

o.HPAClient = kubeClient.AutoscalingV1() // get the generator <del> o.generatorFunc = func(name string, mapping *meta.RESTMapping) (generate.StructuredGenerator, error) { </del> <ins> o.generatorFunc = func(name, refName string, mapping *meta.RESTMapping) (generate.StructuredGenerator, error) { if len(name) == 0 { name = refName } </ins> switch o.Generator { case generateversioned.HorizontalPodAutoscalerV1GeneratorName: return &generateversioned.HorizontalPodAutoscalerGeneratorV1{

MinReplicas:        o.Min, MaxReplicas:        o.Max, CPUPercent:         o.CPUPercent, <del> ScaleRefName:       name, </del> <ins> ScaleRefName:       refName, </ins> ScaleRefKind:       mapping.GroupVersionKind.Kind, ScaleRefAPIVersion: mapping.GroupVersionKind.GroupVersion().String(), }, nil

return fmt.Errorf("cannot autoscale a %v: %v", mapping.GroupVersionKind.Kind, err) } <del> generator, err := o.generatorFunc(info.Name, mapping) </del> <ins> generator, err := o.generatorFunc(o.Name, info.Name, mapping) </ins> if err != nil { return err }
Change:
What would you like to be : Currently, does not have unit test coverage. Specifically, there's no unit test coverage for . I'd like to see unit test coverage for . See for a sample of how to write platform specific unit tests. Why is this needed: There's a fairly small chance of being modified, and thus breaking, in the future without this test coverage. However, it should be relatively straightforward to add the test coverage, and could make a good first issue for a new contributor. There's also the benefit that it helps keep the test coverage in high :) And we never know, it might help catch a bug some day :) Extra note I think this ticket could be a great candidate for someone who is new to contributing to sig-node/k8s. I'd prefer to please give first dibs for picking this up to any folks who are currently underrepresented in the k8s community. Please reach out to on k8s Slack (or post directly in #sig-node and tag me) if you're interested, and I'll assign you the issue. I'm happy to mentor and be helpful in whatever way I can :)
Assigning this to Ali Farah (" (Ali, for some reason it won't let me assign you - can you assign yourself?) /sig node
Thanks ! /assign

Discussion:
go_test( name = "go_default_test", srcs = [ <ins> "bootime_util_linux_test.go", </ins> "util_test.go", "util_unix_test.go", "util_windows_test.go",

<ins> // +build freebsd linux /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package util import ( "testing" "time" ) func TestGetBootTime(t *testing.T) { boottime, err := GetBootTime() if err != nil { t.Errorf("Unable to get system uptime") } if !boottime.After(time.Time{}) { t.Errorf("Invalid system uptime") } } </ins>
Change:
What would you like to be : The Event API is being promoted to v1 in and right now v1beta1 has higher priority than v1 in We should bump this in 1.20. Why is this needed: The new Event API is being promoted.
/sig instrumentation
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
/reopen
Reopened this issue. <detailsIn response to : /reopen </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

Discussion:
utilruntime.Must(events.AddToScheme(scheme)) utilruntime.Must(v1beta1.AddToScheme(scheme)) utilruntime.Must(v1.AddToScheme(scheme)) <del> utilruntime.Must(scheme.SetVersionPriority(v1beta1.SchemeGroupVersion, v1.SchemeGroupVersion)) </del> <ins> utilruntime.Must(scheme.SetVersionPriority(v1.SchemeGroupVersion, v1beta1.SchemeGroupVersion)) </ins> }
Change:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiextensions-apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery

Discussion:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> caesarxuchao deads2k lavalamp </ins> sttts <del> tallclair </del>

# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> cjcullen joelsmith liggitt philips </del> <ins> cheftako deads2k lavalamp </ins> sttts <del> tallclair </del>