jiebi/CodeConvo huggingface dataset:
Change:
requests := make(map[string]int64, len(pods)) for _, pod := range pods { podSum := int64(0) <del> for _, c := range pod.Spec.Containers { </del> <ins> // Calculate all regular containers and restartable init containers requests. containers := append([]v1.Container{}, pod.Spec.Containers...) for _, c := range pod.Spec.InitContainers { if c.RestartPolicy != nil && *c.RestartPolicy == v1.ContainerRestartPolicyAlways { containers = append(containers, c) } } for _, c := range containers { </ins> if container == "" || container == c.Name { if containerRequest, ok := c.Resources.Requests[resource]; ok { podSum += containerRequest.MilliValue()

Discussion:
Calculate sidecar containers resource in pod autoscaler. From 1.28 user could run Sidecar containers in , those sidecar containers remain running during the entire life of the Pod, it should be calculated in . If missing the sidecar resources, we will get a wrong pod resource utilization. We should also correct the related Cadvisor metrics.
/assign /sig autoscaling
/triage accepted /priority important-soon
Change:
}, field.ErrorList{{Type: field.ErrorTypeInvalid, Field: "containers[0].envFrom[0].configMapRef.name"}}, }, <ins> { "Unsupported resize policy for memory", line(), []core.Container{ { Name:                     "resize-policy-mem-invalid", Image:                    "image", ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", ResizePolicy: []core.ContainerResizePolicy{ {ResourceName: "memory", RestartPolicy: "RestartContainerrrr"}, }, }, }, field.ErrorList{{Type: field.ErrorTypeNotSupported, Field: "containers[0].resizePolicy"}}, }, { "Unsupported resize policy for CPU", line(), []core.Container{ { Name:                     "resize-policy-cpu-invalid", Image:                    "image", ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", ResizePolicy: []core.ContainerResizePolicy{ {ResourceName: "cpu", RestartPolicy: "RestartNotRequired"}, }, }, }, field.ErrorList{{Type: field.ErrorTypeNotSupported, Field: "containers[0].resizePolicy"}}, }, </ins> } for _, tc := range errorCases { t.Run(tc.title+"__@L"+tc.line, func(t *testing.T) {

Discussion:
The newly field field is not being validated. field should be validated. We can create a pod with invalid to reproduce this. No response_ <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign /sig node /priority important-soon /milestone v1.27 adding to 1.27 milestone to resolve if possible
I'll try this for v1.27 if you don't mind.
getting a PR open, reviewed, and green is always good. we'll evaluate it for risk and if there's a second release candidate we can likely include it
Nice catch! Please review fix: This likely got dropped either during port-over of the or during bad rebase. I should not have left the . Gotta run to get my kid prepped, dr. appt and then school drop. So I'll try and add an E2E test for this later today. please hold for e2e test (but we should fix this in 1.27)
I realized you were working on a fix as well only after I sent my fix out and was catching up on emails at doc office (rushed morning). I didn't mean to step over your effort to fix it, sorry about that.
I am completely fine with that. Thanks for the fix :)
Change:
expc.recorder.Event(pvc, v1.EventTypeNormal, events.ExternalExpanding, msg) csiResizerName, err := expc.translator.GetCSINameFromInTreeName(inTreePluginName) if err != nil { <del> errorMsg := fmt.Sprintf("error getting CSI driver name for pvc %s, with error %v", util.ClaimToClaimKey(pvc), err) </del> <ins> errorMsg := fmt.Sprintf("error getting CSI driver name for pvc %s, with error %v", key, err) </ins> expc.recorder.Event(pvc, v1.EventTypeWarning, events.ExternalExpanding, errorMsg) return fmt.Errorf(errorMsg) } pvc, err := util.SetClaimResizer(pvc, csiResizerName, expc.kubeClient) if err != nil { <del> errorMsg := fmt.Sprintf("error setting resizer annotation to pvc %s, with error %v", util.ClaimToClaimKey(pvc), err) </del> <ins> errorMsg := fmt.Sprintf("error setting resizer annotation to pvc %s, with error %v", key, err) </ins> expc.recorder.Event(pvc, v1.EventTypeWarning, events.ExternalExpanding, errorMsg) return fmt.Errorf(errorMsg) }

Discussion:
I migrated an existing EBS volume from in-tree plugin to external aws-ebs-csi-driver (). Resizing PVC twice in 6 hour window causes kube-controller-manager to crash. Exception message: Kube-controller-manager shouldn't crash in such case. If external aws-ebs-csi-driver fails to provision the pvc it should just log an warning or error and continue operating as usual running cluster version 1.22.9 using in-tree aws ebs driver. pvc: Install aws-ebs-csi-driver following featureGate CSIMigrationAWS on all cluster components (with draining nodes before enabling featureGate on kubelets - according to warning ) we have ebs volume that has been migrated to aws-ebs-csi-driver. pvc by increasing .spec.resources.request.storage to 2Gi. PVC, PV and EBS volume are correctly resized. once again not later than 6 hours after first resize. Increase .spec.resources.request.storage to 3Gi. Now kube-controller-manager throws an exception and crashes: EBS CSI Driver logs: I tried also enabling alpha featureGate InTreePluginAWSUnregister but the issue still occurs. <details</details<detailsAWS </details<details</details<details</details<detailsdocker </details<detailsaws-ebs-csi-driver version 1.10.0 </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cloud-provider
/sig storage some situation where the sync loop passes a nil parameter to
/assign
SetClaimResizer may return nil pvc and non-nil error, ClaimToClaimKey naively assumes non-nil as described above, will create PR
But the posted bug is I think 1.22 specific and should never happen on master or 1.24 and hence this fix against master is kind of okay and should fix the issue but at the same time code in is still kinda broken in 1.22 because it returns if patching fails.
Change:
} if kl.nodeIP != nil { enforcedNodeAddresses := []v1.NodeAddress{} <ins> var nodeIPType v1.NodeAddressType </ins> for _, nodeAddress := range nodeAddresses { if nodeAddress.Address == kl.nodeIP.String() { enforcedNodeAddresses = append(enforcedNodeAddresses, v1.NodeAddress{Type: nodeAddress.Type, Address: nodeAddress.Address}) <ins> nodeIPType = nodeAddress.Type break </ins> } } if len(enforcedNodeAddresses) > 0 { <ins> for _, nodeAddress := range nodeAddresses { if nodeAddress.Type != nodeIPType && nodeAddress.Type != v1.NodeHostName { enforcedNodeAddresses = append(enforcedNodeAddresses, v1.NodeAddress{Type: nodeAddress.Type, Address: nodeAddress.Address}) } } </ins> enforcedNodeAddresses = append(enforcedNodeAddresses, v1.NodeAddress{Type: v1.NodeHostName, Address: kl.GetHostname()}) node.Status.Addresses = enforcedNodeAddresses return nil

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When using the flag on the kubelet, the node's list no longer reports , , addresses. What you expected to happen: That I can explicitly set to an IP, but the other addresses will still show up. How to reproduce it (as minimally and precisely as possible): Create a new kops cluster, modify the kubelet to use the flag with the eth0 on the node. Run Anything else we need to know?: This change will probably take place in  This came up as a result of Environment: Kubernetes version (use ): 1.9.x Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): any Kernel (e.g. ): any Install tools: kops /sig network /sig node I'll make a PR for this change shortly
Change:
package main import ( <del> "errors" </del> goflag "flag" <del> "fmt" </del> "math/rand" "os" <del> "path" </del> "path/filepath" "time"

Discussion:
Follow up for the deprecation we did in 1.14:
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 /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 : /remove-lifecycle stale /good-first-issue 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 release
I am willing to take this, if it is available :)
go for it. All you need to do is remove and associated code -
I ended up getting hit with the removal of the --make-symlinks flag. I looked at the threads linked to the original PR, but I did not find the actual reason behind the removal. Do you recall was the reason behind removing that capability?
the original request was from
Change:
// NOTE: events received on your eventHandler should be copied before being used. // TODO: figure out if this can be removed. StartEventWatcher(eventHandler func(event runtime.Object)) func() <ins> // Shutdown shuts down the broadcaster Shutdown() </ins> } // EventSink knows how to store events (client-go implements it.)

Discussion:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash
Change:
} } else { // If volume is not safe to detach (is mounted) wait a max amount of time before detaching any way. <del> timeElapsed, err := rc.actualStateOfWorld.MarkDesireToDetach(attachedVolume.VolumeName, attachedVolume.NodeName) if err != nil { glog.Errorf("Unexpected error actualStateOfWorld.MarkDesireToDetach(): %v", err) } </del> if timeElapsed > rc.maxWaitForUnmountDuration { glog.V(5).Infof("Attempting to start DetachVolume for volume %q from node %q. Volume is not safe to detach, but maxWaitForUnmountDuration expired.", attachedVolume.VolumeName, attachedVolume.NodeName) err := rc.attacherDetacher.DetachVolume(attachedVolume.AttachedVolume, rc.actualStateOfWorld)

Discussion:
introduced logic to make kubelet volume manager wait for attach detach controller to finish attach before it starts mount. The controller should also not start a detach operation until the node status has been updated removing the volume from the list of attached volumes. Otherwise if a pod is rapidly created and deleted on the same node, it could result in a mount starting immediately before a detach starts. Props to and his pet set tests for helping catch this.
Hmm, this just happened , just a lot less frequently. Haven't debugged, but it looks like the failed pod did reland on the same node: pet-0, jenkins-e2e-minion-group-4mn2 (). Reopening, will try to confirm when i have time, and close if it's not the same thing.
Just following up with an update, Saad and i are tag teaming this. He's uploading a pr that I'm going to reivew. We're tracking a couple of issues: need to update the "volumes in use" list before polling on the "volumes attached" list. Best option is to write a operation executor, so we don't hammer the apiserver. needs to get up to date node object from apiserver to determine volumes in use. The update that removes volumes from the "attached list" shoud return a fresh node object, we can just iterate the volumes its using (this must happen after popping from attached, though). leaky volumes in the node object (this is not about the physical volumes but about the size of the json blob that's the node object growing). The proposed fix is to use the desired state of the world to update the list of volumes in use. There's a last point I need to follow up on. We might leave the node object in an inconsistent state with the proposed fix, but it should be ok since nothing is checking the inconsistent fields. This will happen if we pop a volume from the attached list, but then find its in use in the updated node object. ping me when you're ready to go, of if you need help
Change:
apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <del> "k8s.io/apimachinery/pkg/runtime" </del> <ins> "k8s.io/apimachinery/pkg/runtime/schema" </ins> "k8s.io/apimachinery/pkg/runtime/serializer" "k8s.io/apiserver/pkg/endpoints/handlers/responsewriters" v1listers "k8s.io/client-go/listers/core/v1"

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): build--5-v1.7.5-3 Environment: Cloud provider or hardware configuration: Laptop (bare metal) OS (e.g. from /etc/os-release): Fedora 26 Kernel (e.g. ): Linux localhost.localdomain 4.11.0-0.rc6.git0.1.fc26.x8664 SMP Mon Apr 10 19:45:50 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: make && hack/local-cluster- -o _output/bin What happened: built from and ran with local-cluster- All commands gave the following error: Running showed the output: What you expected to happen: for commands to work, and Content-type to show How to reproduce it (as minimally and precisely as possible):
ccing
I see the text plain content type, but not kubectl errors
i was using the wrong version of kubectl. updated to new and i'm not getting an error any longer.
Text/plain coming back from the server is still an issue
cc
I'm not seeing against head and the pastebin is gone. Did you reproduce?
I did last week. Insecure and secured port behaved differently
You can reproduce this using against a Kubernetes cluster built from HEAD
Hi all, I think we could use write Content-type correctly. I have made a PR to fix this.
Change:
} cfg := makePodSourceConfig(kcfg) <del> k := createAndInitKubelet(kcfg, cfg) </del> <ins> k, err := createAndInitKubelet(kcfg, cfg) if err != nil { glog.Errorf("Failed to create kubelet: %s", err) return } </ins> // process pods and exit. if kcfg.Runonce { if _, err := k.RunOnce(cfg.Updates()); err != nil {

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
if oldDetachCount >= newDetachCount { return false, nil } return true, nil }

Discussion:
Which jobs are flaking: () () Which test(s) are flaking: Reason for failure: Timeout: Anything else we need to know: This test flaking about 10% of the time in this job. /sig storage /kind flake /priority important-soon cc
/remove-kind failing-test
/assign
I noticed one issue with the test is that it's not filtering metrics by plugin name. So it will just count the last plugin's metric. I'm not sure if the metrics collected are in any sorted order or not. If not, then when you have a suite that runs multiple plugins, then you might be pulling from the wrong metric.
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 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
/remove-lifecycle rotten
still very prevalent in sig-release dashboards
I have pushed which should hopefully fix this.
Also PR against 1.17 branch -
Change:
return errors.Wrapf(err, "%s Deployment", unableToDecodeCoreDNS) } <del> // Create the Deployment for CoreDNS or update it in case it already exists if err := apiclient.CreateOrUpdateDeployment(client, coreDNSDeployment); err != nil { return err </del> <ins> // Create the deployment for CoreDNS or retain it in case the CoreDNS migration has failed during upgrade if hasCoreDNSMigrationFailed { if err := apiclient.CreateOrRetainDeployment(client, coreDNSDeployment, kubeadmconstants.CoreDNSDeploymentName); err != nil { return err } } else { // Create the Deployment for CoreDNS or update it in case it already exists if err := apiclient.CreateOrUpdateDeployment(client, coreDNSDeployment); err != nil { return err } </ins> } coreDNSService := &v1.Service{}

Discussion:
What happened: Upgrade using kubeadm failed because of CoreDNS migration enchancement What you expected to happen: Upgrade passed correctly How to reproduce it (as minimally and precisely as possible): any 1.15.x Kubernetes with CoreDNS that deployed with any unusual image (self built for example). We using commits counter as part of image tag, e.g - 1.6.2-100. to upgrade to 1.16.x with kubeadm. Anything else we need to know?: Logs part without ignoring preflight: Logs part with ignoring preflight: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OpenStack OS (e.g: ):Kernel (e.g. ):Install tools: Kubeadm
/sig cluster-lifecycle
The error came from It seems you should mention this issue on coredns project
True. Will notify them also.
/cc
/assign In such cases where the migration isn't supported and the user chooses to ignore the warnings from the preflight check, the migration should be skipped. wdyt? /cc
Yes. IMO, the warnings should be phrased like "CoreDNS configuration migration will not occur: reason"... so that a user expects the config migration will not be done.
/area kubeadm
SGTM
Upgrade passed correctly I think the best we can do here is to allow the upgrade to pass, but this will, in most practical cases, result in a cluster without a functioning DNS. The most common practical use-case for using a self built image of CoreDNS is to use external plugins. During the kubeadm upgrade, CoreDNS will be replaced with a stock release version of CoreDNS. When that new version of CoreDNS starts, it will not be able to load the existing Corefile's external plugins, and exit. ... or, we could finish the upgrade, leaving the existing CoreDNS deployment untouched, which I think works better.
Yea, it's kinda strong words that "Upgrade passed correctly". Probably, I think the best solution will be to make possible skip Corefile migration and make kubeadm finish the upgrade without Corefile changes. Guys that using custom images of CoreDNS should care about Corefile for new version by themselves, IMO.
Yes, I think that would work best...
Change:
Status: apiextensions.CustomResourceDefinitionStatus{StoredVersions: []string{"version"}}, } } <del> old := fn(tc.storedRule) resource := fn(tc.updatedRule) </del> <ins> old := fn(tc.storedRule, tc.storedMessageExpression) resource := fn(tc.updatedRule, tc.updatedMessageExpression) </ins> t.Run(tc.name, func(t *testing.T) { ctx := context.TODO()

Discussion:
Noticed a copy & paste issue when reading through the CEL code. Basically here: This should be instead of: The impact of this issue should be that messageExpressions are always evaluated with the CEL environment of the compatibility version. But stored (i.e. pre-existing) messageExpressions should be evaluated with a CEL environment with the "max" version instead. For users of Kubernetes this means that messageExpressions deployed with one minor version of Kubernetes might not work anymore if they rollback e.g. by one minor version. messageExpressions should be treated the same way as rules in that regard. Deploy Kubernetes 1.30 Deploy CRD that uses messageExpression that is using Sets (which became available with Kubernetes 1.30 that is using compatibilty version 1.29) Rollback to Kubernetes 1.29 Update something in the CRD =CRD update will fail because messageExpression is evaluated with the wrong CEL environment (it should still work) No response <detailsAt least on Kubernetes main, but I would assume this isuse is there since CEL was implemented </details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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 Will open a PR in a bit