jiebi/CodeConvo huggingface dataset:
Code change:
package gce import ( <del> "errors" </del> "fmt" "strings"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: As part of the initiative for external cloud providers (), we GetZoneByProviderID and GetZoneByNodeName. See for more details. The previous PR did not actually implement those methods for existing cloud providers in . These methods should be implemented by all cloud providers in the future. cc
Could someone add the label and the label for this issue please?
/sig cluster-lifecycle
/area cloudprovider
/assign wlan0
cc We need the following label - help-wanted and add it to the 1.8(?) milestone cc to implement it for their respective clouds.
I'll try to have a look by the end of the week.
Ok, I will take care of the Rackspace and OpenStack.
Thank you !
- Is there any listing where to see the already implemented cloud provider ?
No providers have this yet. Current PRs: Openstack: Rackspace: Please contribute if you have something ready :)
Sorry for the delay guys :)
Have you implemented them for gce?
Intending to work on it tonight, but if you have something I can work on azure
Yes, I have prepared for GCE.
Azure .
Cool, than you all! Any other providers we should implement this for in time for v1.8?
I'll take a look tomorrow to see if there's something left
Let's see which providers are left before closing this...
- I guess this one should be closed ?
If you say that all providers have this now, thanks, great!
Code change:
// features that enable backwards compatibility but are scheduled to be removed // ... <del> HPAScaleToZero:         {Default: false, PreRelease: featuregate.Alpha}, LegacyNodeRoleBehavior: {Default: false, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.22 </del> <ins> HPAScaleToZero: {Default: false, PreRelease: featuregate.Alpha}, </ins> }

Related discussion:
text: What is missing? Based on SIG call it's probably "tests" but I am not sure. Could use some investigation and followup - how do we get it to GA? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
This one seems not a good first one, I'll take this to myself and start bothering people in Slack to check what's missing, mostly as I've seen this is also related to cloud providers :)
I think this one originally. According to the KEP in This should have went GA in v.19 and be removed in v1.20. Given it's still marked beta, at the very least we should mark it GA in v1.20 and remove it in v1.21. anything I'm missing here?
yeap. Honest question, changing a Feature Gate to GA process is only changing the related line in and also putting a comment that this goes to GA? If so, probably this one can also be a good first issue and we can open a future issue for the removal in v1.21 once v1.20 ships. I think this will also need to be changed in the in v1.21 right? If is ok with that, I would like then to mark this as a good first issue to turn the feature GA in v1.20 :)
Well, taking a look into how secure is to move to GA: In the KEP there are some considerations about removing the IsMasterNode function, which seems to be already dealt in commit E2E tests needs to be also checked about usage of IsMasterNode(), which I could not find anymore and also seems to be removed from the same commit above. About the same Kep, it's directly related to other Feature Gate: ` So what I think that needs to be done: Promote LegacyNodeRoleBehavior to GA and Default it to false as proposed in the Kep -I'll open another issue just for this According to the LegacyNodeRoleBehavior should be removed in v1.19 but according to the Kep in v1.21, so let's stick with v1.21? ServiceNodeExclusion - Should be moved to GA, already defaulted to true. This issue is going to deal ONLY with this.
Code change:
// features that enable backwards compatibility but are scheduled to be removed // ... <del> HPAScaleToZero:         {Default: false, PreRelease: featuregate.Alpha}, LegacyNodeRoleBehavior: {Default: false, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.22 </del> <ins> HPAScaleToZero: {Default: false, PreRelease: featuregate.Alpha}, </ins> }

Related discussion:
text: NodeDisruptionExclusion - Should be moved to GA, already defaulted to true. I'll open another issue for this I'm afraid of this having some sort of direct impact in cloud providers, do you want me to take this to the sig-cloudproviders meet? Otherwise can we move the above Feature Gates to GA, and schedule their removal for v1.21, wdyt?
Per deprecation lifecycle it seems that a feature needs 6 months or 2 releases (the longer one) in Beta before going to GA. So this actually seems to be the missing part before moving to GA. As the 3 FeatureGates are directed related, probably this issue should be: Move all of them to GA in v1.21 Default LegacyNodeRoleBehavior to false Sounds a good approach? I can keep this opened until we reach v1.21
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
/retitle Move Feature gate ServiceNodeExclusion to GA and LockToDefault
/triage accepted as this FG is scheduled to be moved to GA in v1.21, do you want to tackle on this?
fixed in /close
Closing this issue. <detailsIn response to : fixed in /close </details
Code change:
"//pkg/apis/core/v1/helper:go_default_library", "//pkg/apis/storage/v1/util:go_default_library", "//pkg/client/conditions:go_default_library", <ins> "//pkg/kubelet/events:go_default_library", </ins> "//pkg/kubelet/metrics:go_default_library", "//pkg/util/slice:go_default_library", "//pkg/volume/util:go_default_library",

Related discussion:
text: <!-- 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?: What happened: This feature is lacking coverage, especially for containerized kubelet environments.
/assign since I'm the owner of this feature.
And just fixes a bug for containerized kubelet when the mount file is an empty file.
Are we going to enable these tests in v1.11? We're getting code freeze soon.
There is a local containerized cluster pull and CI job that we can probably leverage. Right now it only runs conformance tests, we may be able to add new suites to enable other tests. Cc who can point us to the owner for the containerized testing effort
yes, seems to be holding up pretty well - https://k8s-,%20master%20(dev)
In I made pull-kubernetes-local-e2e-containerized to run also all test with string. I'm enabling some tests (subpath!) in , feel free to suggest more tests.
Ref
IIUC, the default host path type is . And when host path type is , we expect container runtime to create the host path if it doesn't exist (docker is doing that today). Is that true? If that is, we should revert part of , because container runtime should still create host path if it does not exist. /cc I tried to enforce , and got a lot of errors , e.g.:
Correct. This is mainly for backwards compatibility.
I see. If so, I'll remove the CRI definition "If the hostPath doesn't exist (e.g. hostPath volume), runtimes should report errors". Thanks!
SGTM. Refer to .
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 will help fix this.
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.
Code change:
"//pkg/apis/core/v1/helper:go_default_library", "//pkg/apis/storage/v1/util:go_default_library", "//pkg/client/conditions:go_default_library", <ins> "//pkg/kubelet/events:go_default_library", </ins> "//pkg/kubelet/metrics:go_default_library", "//pkg/util/slice:go_default_library", "//pkg/volume/util:go_default_library",

Related discussion:
text: 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
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
/remove-lifecycle rotten
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
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
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 .
Code change:
"//pkg/apis/core/v1/helper:go_default_library", "//pkg/apis/storage/v1/util:go_default_library", "//pkg/client/conditions:go_default_library", <ins> "//pkg/kubelet/events:go_default_library", </ins> "//pkg/kubelet/metrics:go_default_library", "//pkg/util/slice:go_default_library", "//pkg/volume/util:go_default_library",

Related discussion:
text: 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
Code change:
} } <ins> // FinalError constructs an error that indicates to a poll function that // polling can be stopped immediately because some permanent error has been // encountered that is not going to go away. // // TODO (@pohly): move this into framework once the refactoring from // https://github.com/kubernetes/kubernetes/pull/112043 allows it. Right now it // leads to circular dependencies. func FinalError(err error) error { return &FinalErr{Err: err} } type FinalErr struct { Err error } func (err *FinalErr) Error() string { if err.Err != nil { return fmt.Sprintf("final error: %s", err.Err.Error()) } return "final error, exact problem unknown" } func (err *FinalErr) Unwrap() error { return err.Err } // IsFinal checks whether the error was marked as final by wrapping some error // with FinalError. func IsFinal(err error) bool { var finalErr *FinalErr return errors.As(err, &finalErr) } </ins> // maybeTimeoutError returns a TimeoutError if err is a timeout. Otherwise, wrap err. // taskFormat and taskArgs should be the task being performed when the error occurred, // e.g. "waiting for pod to be running".

Related discussion:
text: treats any error returned by the condition as terminal, but silently ignores any errors that aren't returned along with . We should change WaitForPodCondition to behave like . /sig testing /area e2e-test-framework
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
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]:
/remove-lifecycle stale
Was there any reason why you instead of doing this right away? I fully agree with this issue, we should abort early. I just found the TODO because I have a failing test that ran longer than expected after a final pod failure and that made me check out why it didn't abort quicker :grin:
Code change:
executor := exec.New() args := []string{"trigger"} <del> cmd := executor.Command("/usr/bin/udevadm", args...) </del> <ins> cmd := executor.Command("udevadm", args...) </ins> _, err := cmd.CombinedOutput() if err != nil { glog.Errorf("error running udevadm trigger %vn", err)

Related discussion:
text: I am running into a problem with the Cinder plugin when running Kubernetes inside Docker using the kube-deploy/docker-multinode project I modified the worker and master scripts of the latter project such that: --cloud-provider and --cloud-config options are to the hyperkube command I mount a host dir with the cloud_config file into the kubelet container (with the -v option) The cinder plugin of kubernetes (for attaching Openstack Cinder volumes) attaches a volume successfully and then tries to find the corresponding device. However the cinder plugin can't find this device by disk-id: The last log entry shows a failure to run . I tried to run this command from within a bash session inside the kubelet container and then got as error: How can I solve this? Thanks for any advice
CC
It basically tries to run to probe all attachments so sym link for the disk is created in . Is this the command you tried to run from command line?
Yes. However I now see that I misread the debuglogs that the full command was the following: . But this is wrong syntax obviously I launched Kubernetes version 1.2.6 in the dockerized version of hyperkube. I assume that the error lies somewhere in the fact that certain commands don't work properly when run inside a container. To further debug, I just had a look at the code from that reported the error (see below). First an executor is created using . Then this executor is asked to execute command . The implementation of the executor will try to execute the command in a child process (hence the fork)
I think I'm running into a related issue, or at least the same root cause. When using PV+PVC Cinder volumes the Kubelet fails to confirm that they are attached (even though I see the volume is attached in Horizon). The same error shows in the kubelet logs: However, on Ubuntu 16.04 at least, is located in a different place:
Adding a symlink to the correct location seems to have resolved the issue for me:
Code change:
- --memory={{ base_metrics_server_memory }} - --extra-memory={{ metrics_server_memory_per_node }}Mi - --threshold=5 <del> - --deployment=metrics-server-v0.3.0 </del> <ins> - --deployment=metrics-server-v0.3.1 </ins> - --container=metrics-server - --poll-period=300000 - --estimator=exponential

Related discussion:
text: This started after was merged. The HPA test started being very flaky since then: https://k8s- The HPA test in containerd e2e become even more flaky since then with the same failure pattern: https://k8s-
I think this is probably /priority critical-urgent Release team hasn't looked close enough at this issue as we've been trying to clear other issues in front of it. If we crack those and this is unrelated root cause, then this one's going to be a release blocker.
It's going to be supremely hard to debug this unless we have logs from metrics-server and/or snapshots of the HPA over time. I'm trying to reproduce on a local cluster, but so far, the test passes consistently. did you manage to reproduce locally?
is there any way to grab logs of pods from a testing cluster?
you probably want to save it as part of the artifacts?
yeah, what's the process for that?
somewhere along
See for an attempt at debugging this.
can we provide the data is looking for? we're seeing this quite often.
ack, more logs would be helpful. Currently trying to get usable logs off the CI with the aforementioned PR, but I keep making minor mistakes in the log collection script :-/. It seems to repro every few runs though, so with any luck I'll see it again soon.
Got a WIP fix up: Need to do one more tweak before merge.
Re-running tests with the above PR, if they succeed I'll merge and get someone to do a build when the people capable of running builds are on next.
status check? I'm worried this is a 1.12 blocker and need to make a call by end of day today regarding delaying the release.
According to our testing, metrics-server 0.3.1 seems to have fixed it - thank you
Code change:
- '/event-exporter' # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: gcr.io/google-containers/prometheus-to-sd:v0.2.1 </del> <ins> image: gcr.io/google-containers/prometheus-to-sd:v0.2.2 </ins> command: - /monitor <del> - --component=event_exporter </del> - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons - --api-override={{ prometheus_to_sd_endpoint }} <del> - --whitelisted-metrics=stackdriver_sink_received_entry_count,stackdriver_sink_request_count,stackdriver_sink_successfully_sent_entry_count volumeMounts: - name: ssl-certs mountPath: /etc/ssl/certs </del> <ins> - --source=event_exported:http://localhost:80?whitelisted=stackdriver_sink_received_entry_count,stackdriver_sink_request_count,stackdriver_sink_successfully_sent_entry_count - --pod-id=$(POD_NAME) - --namespace-id=$(POD_NAMESPACE) env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace </ins> # END_PROMETHEUS_TO_SD terminationGracePeriodSeconds: 30 volumes:

Related discussion:
text: Currently there are several, and some of them have problems with excessive logging could you please do this?
Any estimate on this fix? Asking because I'm seeing the issue referenced in
It was already fixed in head and in 1.8 long time ago. Fix was merged to 1.7 recently, so we are just waiting for new patch release.
Code change:
{ genericapirequest.RequestInfo{ APIGroup:   "apps", <ins> APIVersion: "v1", Resource:   "daemonsets", }, map[string]string{"a": "b"}, map[string]string{"c": "d"}, field.ErrorList{ &field.Error{ Type:  field.ErrorTypeInvalid, Field: field.NewPath("spec").Child("selector").String(), BadValue: &metav1.LabelSelector{ MatchLabels:      map[string]string{"c": "d"}, MatchExpressions: []metav1.LabelSelectorRequirement{}, }, Detail: "field is immutable", }, }, }, { genericapirequest.RequestInfo{ APIGroup:   "apps", </ins> APIVersion: "v1beta2", Resource:   "daemonsets", },

Related discussion:
text: /priority failing-test /priority critical-urgent /sig apps This test case has been failing for a while and affects a number of jobs: This is affecting multiple jobs on the testgrid dashboard, and prevents us from cutting 1.9.0-alpha.2 (kubernetes/sig-release). Is there work ongoing to bring this job back to green?
All test failures look similar: . ~Is it due to network issue instead of DaemonSet?~
This seems related to the new DaemonSet. The connection refused error is happening because kube-apiserver is crashing:
needs an update
Ah, well... I guess it's halfway working as intended. We put that there to make the tests fail if we forgot to update it when adding a new version. We had hoped it would fail during presubmit tests though. :(
Sending a fix now
I wonder why the test is not failing on submit queue tests. Do i need to fix deployment and replicaset?
The rest of the group is not merged, and the v1 PR takes the selector mutability into account.
Since this bug crashes apiserver I'd expect it to affect many other e2e tests.
Noted, we need to fix deployment and replicaset when the v1 PR is merged.
Not quite sure how this test isn't failing before but is now consistently failing. I'd expect the commit that triggers this to block the submit queue. The e2e test is still accessing DaemonSet through extensions/v1beta1 endpoints. From the above apiserver log it's hard to tell what updates DaemonSet via apps/v1 before the code panics. I tried to reproduce it locally, and found that garbage collector PUT apps/v1 DaemonSet:
When apps/v1 gets introduced, it may be ordered before apps/beta1 alphabetically. IIRC, there is a code change on the apps/v1 PR that changes the order of API versions such that apps/v1 is ranked before apps/v1beta2 and apps/v1beta2 before apps/v1beta1. Perhaps this problem can be fixed when the PR merges.
Since crashes apiserver and makes debugging harder, which defeats the purpose of using it, we should return error on unsupported versions instead.
The first run with this change is still in progress, but this test already passed: https://k8s- Thanks for the quick fix
Code change:
"os" "path" "reflect" <ins> "regexp" </ins> "sort" "strings" "sync"

Related discussion:
text: <!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Unknown yet. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig scheduling /help
Can I give it a try?
Sure, feel free to take it. /assign ahmad-diaa /remove-help
I keep trying to get it fail locally by running the following command: but it never does, am I doing something wrong? Is there something else that I should be doing and would be more helpful?
Sometimes the flake is hard to reproduce in local env. You may have to read the error log of the flakes thoroughly to get some clues. BTW: you can also run the test multiple times using the directive:
After looking through the logs I came up with some information that might be useful As far as I understand, the reason for the flake is the of the medium priority pod not being cleared That is because the update request for removing returns the following error: So my current guess is that might be outdated in some cases As I am not really familiar with the logic, I would like to know whether or not those are valid points so that I could dig deeper. What do you think?
If that's the case, you can set here: You can raise a PR and manually try for ~20 times to see you can reproduce the flake.
found another issue tracking this too. it seems it has been flaky for a while.
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution.
This sometimes happens. But we usually take the first PR unless it's clearly worked by someone. In terms of which style to resolve the Conflict error, I'm asking here:
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution. No worries, I haven't started implementing yet and your PR seems to be following the correct approach as well according to this: