jiebi/CodeConvo huggingface dataset:
Code change:
}, { "ImportPath": "github.com/json-iterator/go", <del> "Rev": "f2b4162afba35581b6d4a50d3b8f34e33c144682" </del> <ins> "Rev": "ab8a2e0c74be9d3be70b3184d9acc634935ded82" </ins> }, { "ImportPath": "github.com/modern-go/concurrent",

Related discussion:
text: /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.
Code change:
<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: multiple-certs

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority important-soon /sig network
Ref:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
my fu points me to this commit [] Fix multiple conversion tests that belongs to this PR , that seems related can you confirm if that PR is causing this test to fail? (should we gate on this test?)
Yes, that PR is related to the failure. The test utility is trying to convert extensions/v1beta1 data read from various files directly to a go type. This was never a valid thing to do, and happened to silently succeed because the two structs had an identical structure. This is exactly the type of bug was designed to flush out
the correct fix is to update the test/e2e/testing- files to
/assign
It was my PR that broke this - I can also fix that.
Thanks, o it was the commit that was good but the test that was wrong :upsidedownface: , At least I got right the commit :sweat_smile:
is out for review (talked with offline, he was aware that I'll send that out)
Code change:
return pullSecrets } <del> // Returns true if pod is in the terminated state ("Failed" or "Succeeded"). </del> <ins> // podIsTerminated returns true if pod is in the terminated state ("Failed" or "Succeeded"). </ins> func (kl *Kubelet) podIsTerminated(pod *v1.Pod) bool { <del> var status v1.PodStatus </del> // Check the cached pod status which was set after the last sync. status, ok := kl.statusManager.GetPodStatus(pod.UID) if !ok {

Related discussion:
text: pointed out that for scheduling and kubelet admission, we should consider resources of terminated-but-not-yet-deleted pods to still be in use, because it may take an arbitrary amount of time for the system to deallocate resources. We didn't check to see if this is currently how it is implemented or not. cc/ /sig scheduling
cc/
For terminated-but-not-yet-deleted & phase is case, the Pod is still in scheduler's cache, so it's handled well in scheduler; the Pod will be removed from cache when it's deleted. But in kubelet, it filtered terminated-but-not-yet-deleted out () when using scheduler.predicates. The option in my mind is to ~pass all Pods (including terminated-but-not-yet-deleted) to each admin, and let each admin decide whether filter terminated-but-not-yet-deleted out~ only filter out finished (Failed or Succeed) pods for Admits.
In -, it already consider by . So both scheduler & kubelet handles terminated-but-not-yet-deleted pods well.
Great, thanks for looking into it!
should this issue be closed then?
I think so.
Just to clarify: Kubelet correctly accounts the resources used by terminated-but-not-yet-deleted pods, i.e, kubelet does not count the resource usage of those pods towards total usage on the node. Scheduler, however, does not do the same. Scheduler waits for a pod to be deleted, and then it deducts its resource request from the associated node total usage. Upon deletion of a pod, scheduler is notified and acts: So, scheduler and kubelet behaviors are not exactly the same. I am not sure if scheduler can receive an event when a pod's container status changes. If it could, we could make the logic the same as that of Kubelet.
I guess the current behavior is OK because it is conservative (scheduler considers the resources to be in use even though kubelet considers them free). And actually it seems that scheduler is more "correct" than kubelet, since the resources really aren't usable until the pod is deleted, right? (IIUC that was Vish's original point)
I agree. The current behavior is correct, but a bit conservative. Basically, the scheduler side is more conservative and waits until a pod is deleted from the cache before considering its resources released.
Code change:
return pullSecrets } <del> // Returns true if pod is in the terminated state ("Failed" or "Succeeded"). </del> <ins> // podIsTerminated returns true if pod is in the terminated state ("Failed" or "Succeeded"). </ins> func (kl *Kubelet) podIsTerminated(pod *v1.Pod) bool { <del> var status v1.PodStatus </del> // Check the cached pod status which was set after the last sync. status, ok := kl.statusManager.GetPodStatus(pod.UID) if !ok {

Related discussion:
text: That said, I believe resources of terminated-but-not-deleted pods are usable on nodes (should be verified). So, the current behavior is a bit less than ideal in terms of efficiency, but AFAIK the duration between termination and deletion is only a few seconds. So, it may not be worth optimizing.
I thought was saying the opposite (see my first entry in this issue). Maybe he can clarify.
Code change:
} } <ins> func isCertsVolumeMountNeeded() bool { // Always return true for now. We may add conditional logic here for images which do not require host mounting /etc/ssl // hyperkube for example already has valid ca-certificates installed return true } </ins> // certsVolume exposes host SSL certificates to pod containers. func certsVolume(cfg *kubeadmapi.MasterConfiguration) api.Volume { return api.Volume{

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? controller /etc/ssl/certs kubeadm /etc/ssl/certs 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 ): 5 custom built master I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ... Environment: Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): CentOS 7.2 Kernel (e.g. ): Linux ma-kub8ms0 3.10.0-327.36.3.el7.x8664 SMP Mon Oct 24 16:09:20 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others: deployed with Azure RM template and ansible What happened: controller is not able to do https, including calls to the Azure RM API What you expected to happen: https should work as usual How to reproduce it (as minimally and precisely as possible): Use kubeadm to install kubernetes on CentOS exec into the controller and try "curl " Anything else do we need to know: It looks like caused this issue. On CentOS, I see these files on the host OS: I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image. I also tried to verify this with It seems to not be based on Debian and thus gives a different error: I see 2 possible solutions: of host mounting /etc/ssl/certs into the controller pod, the ca certificates could be installed into the image.
Code change:
} } <ins> func isCertsVolumeMountNeeded() bool { // Always return true for now. We may add conditional logic here for images which do not require host mounting /etc/ssl // hyperkube for example already has valid ca-certificates installed return true } </ins> // certsVolume exposes host SSL certificates to pod containers. func certsVolume(cfg *kubeadmapi.MasterConfiguration) api.Volume { return api.Volume{

Related discussion:
text: This is already done for hyperkube and would work out of the box when the host mount would be omitted. could try to figure out if /etc/pki should also be host mounted and add this to the controller manifest if required. I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
Same problem seems to apply to the apiserver. Not sure however if it actually does https calls.
implements solution 2.
This issue was moved to kubernetes/kubeadm
Code change:
package azure import ( <ins> "context" </ins> "fmt" "reflect" "testing"

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: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Code change:
<del> apiVersion: v1 kind: Service metadata: name: elasticsearch labels: component: elasticsearch spec: type: LoadBalancer selector: component: elasticsearch ports: - name: http port: 9200 protocol: TCP - name: transport port: 9300 protocol: TCP </del>

Related discussion:
text: Presently, the elasticsearch example Kubernetes configurations target elasticsearch v1.7.1, which is quite old. As of this writing, the latest elasticsearch release is v5.6.2, with many deployment changes since then. Could the elasticsearch examples be updated to target the v5 series of elasticsearch? See for a more up to date reference configuration.
cc
hey it's been a long while since I last contributed to the docs. i can do it soon but i need pointers on how to properly do it.
hey, so we need to update the stuff under examples/elasticsearch/ *&repos=kubernetes So basically update the images, yaml files etc and test that everything works (and submit a PR)
/sig testing
Ah, so there's no documentation updates anymore. OK I'll take care of it, assign it to me.
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
GitHub didn't allow me to assign the following users: me. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign me 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 pires
/remove-lifecycle stale
it seems that the example moved to I am now reading that repo guidelines and will update this there. I'll also open a PR that cleans this folder in the current repo and closes this issue.
Code change:
// If selectedNode is set, the driver must attempt to allocate for that // node. If that is not possible, it must return an error. The // controller will call UnsuitableNodes and pass the new information to <del> // the scheduler, which then will lead to selecting a diffent node </del> <ins> // the scheduler, which then will lead to selecting a different node </ins> // if the current one is not suitable. // // The Claim, ClaimParameters, Class, ClassParameters fields of "claims" parameter

Related discussion:
text: When ResourceClaimParameters or ResourceClassParameters fail validation in resource driver during PodSchedulingContext sync loop, the error is visible only in the events of the PodSchedulingContext. The error should be visible on the object that fails validation as well, ResourceClaim or ResourceClass respectively. Creating ResourceClaim with unsupported parameters' values or unsupported No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig node
/triage accepted
KEP:
Code change:
} } <ins> func TestMatchImageTagOrSHA(t *testing.T) { for _, testCase := range []struct { Inspected dockertypes.ImageInspect Image     string Output    bool }{ { Inspected: dockertypes.ImageInspect{RepoTags: []string{"ubuntu:latest"}}, Image:     "ubuntu", Output:    true, }, { Inspected: dockertypes.ImageInspect{RepoTags: []string{"ubuntu:14.04"}}, Image:     "ubuntu:latest", Output:    false, }, { Inspected: dockertypes.ImageInspect{ ID: "sha256:2208f7a29005d226d1ee33a63e33af1f47af6156c740d7d23c7948e8d282d53d", }, Image:  "myimage@sha256:2208f7a29005d226d1ee33a63e33af1f47af6156c740d7d23c7948e8d282d53d", Output: true, }, { Inspected: dockertypes.ImageInspect{ ID: "sha256:2208f7a29005d226d1ee33a63e33af1f47af6156c740d7d23c7948e8d282d53d", }, Image:  "myimage@sha256:2208f7a29005", Output: false, }, { Inspected: dockertypes.ImageInspect{ ID: "sha256:2208f7a29005d226d1ee33a63e33af1f47af6156c740d7d23c7948e8d282d53d", }, Image:  "myimage@sha256:2208", Output: false, }, } { match := matchImageTagOrSHA(testCase.Inspected, testCase.Image) assert.Equal(t, testCase.Output, match, testCase.Image+" is not a match") } } </ins> func TestApplyDefaultImageTag(t *testing.T) { for _, testCase := range []struct { Input  string

Related discussion:
text: We had rather strange case today when after rolling update one of the kubelet's started wrong container. For this specific replicationcontroller we are using What happened was that after rolling-update when i started to debug the issue i discovered that one of the kubelet's did not pull the image: When looking into what image it actually started i saw: When checking from the actual node i saw this It seems that instead of starting myimage with tag 2208 kubelet started image tagged as 1393 since the docker image id starts with 2208.
Code change:
// Volume is added to asw, volume should be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> // Delete the pod dsw.DeletePod(types.UniquePodName(podName1), generatedVolumeName, nodeName1)

Related discussion:
text: TestRunOneVolumeDetachFailNodeWithReadWriteOnce 4 times since 03-19 23:00 PDT, intermittently ! https://k8s- Still investigating whether this is a tolerable flake or not with more history than testgrid view, or otherwise would appreciate input from anyone with expertise in this test, especially as regards to whether this should be a blocker for tomorrows beta cut. maybe: /sig storage /sig testing
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
is already open for this, looks like it is attempting to fix it
thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. /close
Closing this issue. <detailsIn response to : thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. 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
Code change:
// Volume is added to asw, volume should be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> // Delete the pod dsw.DeletePod(types.UniquePodName(podName1), generatedVolumeName, nodeName1)

Related discussion:
text: pull-kubernetes-unit TestRunOneVolumeDetachFailNodeWithReadWriteOnce Jan 7th, 2022 Check volume <fake-plugin/volume-nameis reported as attached to node <fail-detach-node, got false, expected true No response_ /sig storage
/cc
this is the top unit test flake according to
cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
I think this test is no longer flaky by checking the test grid, close it now.
Unfortunately this does still seem to be flaky: Here was the output from : /reopen
Reopened this issue. <detailsIn response to : Unfortunately this does still seem to be flaky: 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 stale
still the case
How about adding some logging to help troubleshoot this? I looked at it a little, but it is hard to tell which part of the test is failing. PR
/
This is still happening
/triage accepted
From the logs, in the OneVolumeDetachFailNodeWithReadWriteOnce test, succeeded, but the next verification failed. In verifyVolumeAttachedToNode, the attachState is from calling and within asw, it calls . In verifyVolumeReportedAsAttachedToNode, the volumes are obtained from calling , it seems that the node is not in asw.nodesToUpdateStatusFor at this step. Cannot reproduce locally. I tried to run the test 100 times locally with debug.Stack()... 3 * 100 times all passed.
Tried to run stress test on my linux machine as well but still cannot reproduce. Command: Result: Also tried running n process in parallel. Command: Result:
It seems like it happens more frequently.
Code change:
// Volume is added to asw, volume should be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> // Delete the pod dsw.DeletePod(types.UniquePodName(podName1), generatedVolumeName, nodeName1)

Related discussion:
text: But I may have no time to dig into the cause. Let's see.
cc as the test author.
The problem is that this test has a lot of dependency on the sleeps that are hardcoded with a very narrow scope, but our CI seems to be able to stress it much more. As soon as you slightly change one of the sleep duration it starts to flake locally The test can not make an assumption that timing is perfect, even more in the sub second range can someone in sig-storage review this test and make it less dependant on those tight sleeps?
According to most failures, it failed at Line 660. Let me run some stress locally. with 250ms sleep with 100ms sleep
I agree this test case is too brittle due to its specific timing dependencies. To fix this, I suggest reworking the test case to: 1) Add retry with timeout to wait for final conditions 2) Remove the intermediate timing-based state transition checks. Instead, we can keep track of state transitions in the Fakes and validate those stats. wdyt?
Friendly ping from 1.27 CI Signal that this test is still a noisy flake on the master-blocking dashboard as CI Signal has flagged it in and