jiebi/CodeConvo huggingface dataset:
Code change:
// Enable pods to set sysctls on a pod Sysctls featuregate.Feature = "Sysctls" <del> // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // ga:  v1.21 // // Enable legacy behavior to vary cluster functionality on the node-role.kubernetes.io labels. On by default (legacy), will be turned off in 1.18. // Lock to false in v1.21 and remove in v1.22. LegacyNodeRoleBehavior featuregate.Feature = "LegacyNodeRoleBehavior" // owner @brendandburns // kep: http://kep.k8s.io/1143 // alpha: v1.9 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from service load balancers ServiceNodeExclusion featuregate.Feature = "ServiceNodeExclusion" // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from network disruption checks NodeDisruptionExclusion featuregate.Feature = "NodeDisruptionExclusion" </del> // owner: @pospispa // GA: v1.11 //

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:
// Enable pods to set sysctls on a pod Sysctls featuregate.Feature = "Sysctls" <del> // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // ga:  v1.21 // // Enable legacy behavior to vary cluster functionality on the node-role.kubernetes.io labels. On by default (legacy), will be turned off in 1.18. // Lock to false in v1.21 and remove in v1.22. LegacyNodeRoleBehavior featuregate.Feature = "LegacyNodeRoleBehavior" // owner @brendandburns // kep: http://kep.k8s.io/1143 // alpha: v1.9 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from service load balancers ServiceNodeExclusion featuregate.Feature = "ServiceNodeExclusion" // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from network disruption checks NodeDisruptionExclusion featuregate.Feature = "NodeDisruptionExclusion" </del> // owner: @pospispa // GA: v1.11 //

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:
} // LocalEndpoint returns the full path to a unix socket at the given endpoint <del> func LocalEndpoint(path, file string) string { </del> <ins> func LocalEndpoint(path, file string) (string, error) { </ins> u := url.URL{ Scheme: unixProtocol, Path:   path, } <del> return filepath.Join(u.String(), file+".sock") </del> <ins> return filepath.Join(u.String(), file+".sock"), nil </ins> }

Related discussion:
text: What happened: I replaced the kubelet on one of my 1.14 nodes with a build from master, and now I'm getting this error starting up. Test passes since 5/31/2019 commit have been failing on testgrid. If you look at the logs, the Windows nodes are not coming up. What you expected to happen: No errors starting up kubelet How to reproduce it (as minimally and precisely as possible): Build master, then try to run the kubelet on Windows Anything else we need to know?: /sig windows Environment: Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..529 Install tools: aks-engine
cc /priority critical-urgent
/milestone v1.15 Release team - it looks like a recent PR broke windows nodes. We will need a fix here for 1.15
Ok, so the problem here is a little more complicated and we're actually seeing a bug that is actually in the code for quite some time, just that we never used that particular code path. But first: TL;DR: Quick fix is to start the kubelet on Windows with: --feature-gates="KubeletPodResources=false" Now, as to why this is happening: PR [1] was merged 3 days ago and it graduates KubeletPodResources feature as Beta. That means kubelet will enable it by default.With the introduction of the above feature, this branch of code is entered when starting kubelet [2]. We can see a call to the function: defined here [3].While innocent enough, gets the necessary npipe by calling: . is defined here [4] for Windows . The problem is actually that url.URL can't handle Windows style paths [5] and will replace "" with "%5C" as it's to be expected. The paths are transformed along the way from the default "/var/lib/kubelet" to "varlibkubelet" by defined here [6]. More specifically in the use of to create a path. It's inputs are unix style but returns the path Windows style as it's to be expected.The solution is to replace the usage of url.URL in with some alternative package or just implement it.
Code change:
} // LocalEndpoint returns the full path to a unix socket at the given endpoint <del> func LocalEndpoint(path, file string) string { </del> <ins> func LocalEndpoint(path, file string) (string, error) { </ins> u := url.URL{ Scheme: unixProtocol, Path:   path, } <del> return filepath.Join(u.String(), file+".sock") </del> <ins> return filepath.Join(u.String(), file+".sock"), nil </ins> }

Related discussion:
text: [1] [2] [3] [4] [5] [6]
Thanks for the analysis! I was a bit concerned around the fact that this started showing up around my commit: but the root cause here is indeed, as you said, the graduation of feature to Beta and the way the invalid escape sequences are being introduced.
GCE tests failing too /cc
I'm trying a quick to see if anything else is broken. There are other functions in that same file doing that substitution already so it may make sense to use that as a workaround until a better solution is available.
Still working on it - looks like the path to create the directories is also busted. With still getting
Code change:
//UploadCerts save certs needs to join a new control-plane on kubeadm-certs sercret. func UploadCerts(client clientset.Interface, cfg *kubeadmapi.InitConfiguration, key string) error { <del> fmt.Printf("[upload-certs] Storing the certificates in ConfigMap %q in the %q Namespacen", kubeadmconstants.KubeadmCertsSecret, metav1.NamespaceSystem) </del> <ins> fmt.Printf("[upload-certs] Storing the certificates in Secret %q in the %q Namespacen", kubeadmconstants.KubeadmCertsSecret, metav1.NamespaceSystem) </ins> decodedKey, err := hex.DecodeString(key) if err != nil { return err

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: (as documented ) reports this: But certificates are actually stored in a Secret (not ConfigMap) by that name and in that namespace. The message printed by kubeadm should be changed accordingly. /sig cluster-lifecycle Environment: Kubernetes version (use ): 1.14.1 Cloud provider or hardware configuration: n/a OS (e.g: ): Debian Install tools: kubeadm
Code change:
return rt.Response, rt.Err } <ins> func TestMaskValue(t *testing.T) { tcs := []struct { key      string value    string expected string }{ { key:      "Authorization", value:    "Basic YWxhZGRpbjpvcGVuc2VzYW1l", expected: "Basic <masked>", }, { key:      "Authorization", value:    "basic", expected: "basic", }, { key:      "Authorization", value:    "Basic", expected: "Basic", }, { key:      "Authorization", value:    "Bearer cn389ncoiwuencr", expected: "Bearer <masked>", }, { key:      "Authorization", value:    "Bearer", expected: "Bearer", }, { key:      "Authorization", value:    "bearer", expected: "bearer", }, { key:      "Authorization", value:    "bearer ", expected: "bearer", }, { key:      "Authorization", value:    "Negotiate cn389ncoiwuencr", expected: "Negotiate <masked>", }, { key:      "ABC", value:    "Negotiate cn389ncoiwuencr", expected: "Negotiate cn389ncoiwuencr", }, { key:      "Authorization", value:    "Negotiate", expected: "Negotiate", }, { key:      "Authorization", value:    "Negotiate ", expected: "Negotiate", }, { key:      "Authorization", value:    "negotiate", expected: "negotiate", }, { key:      "Authorization", value:    "abc cn389ncoiwuencr", expected: "<masked>", }, { key:      "Authorization", value:    "", expected: "", }, } for _, tc := range tcs { maskedValue := maskValue(tc.key, tc.value) if tc.expected != maskedValue { t.Errorf("unexpected value %s, given %s.", maskedValue, tc.value) } } } </ins> func TestBearerAuthRoundTripper(t *testing.T) { rt := &testRoundTripper{} req := &http.Request{}

Related discussion:
text: This issue seems CVE-worthy to me: loss of confidentiality (bearer tokens) + cross of privilege boundary (debug log level could be set by admin, then logs read later by low privileged user). My draft cvss would be: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3)
Two potential vectors: local user with access to system logs (local access, low privilege) (4.7) remote user with access to system logs (network access, high privilege): (4.4) CVE-2019- has been assigned to this issue.
If you want to, go ahead
- should this have the official CVE feed label ( retrospectively, I mean)?
probably? I have no idea how that label is supposed to get applied, but there appear to be several CVE issues that don't have it -
I think you're likely to know who to highlight this to. Sorry to mention you individually; please feel free to point out docs if there are any.
/label official-cve-feed thanks for the tag, the label now!
thanks for the useful filter. Currently in-scope issues are issues that were closed as fixed by code changes to k/k. So with that in mind, I have the labels to some of the closed issues too that conform to the scope defined here:
I would like to reply nearly four years later: There are valid cases to want to see the token, for example my current case, trying to debug token validation between the API server and other services.
Code change:
Expect(err).ToNot(HaveOccurred()) }) }) <ins> Context("Pods sharing a single local PV [Serial]", func() { var ( pv *v1.PersistentVolume ) BeforeEach(func() { localVolume := &localTestVolume{ node:            config.node0, hostDir:         "/tmp", localVolumeType: DirectoryLocalVolumeType, } pvConfig := makeLocalPVConfig(config, localVolume) var err error pv, err = framework.CreatePV(config.client, framework.MakePersistentVolume(pvConfig)) framework.ExpectNoError(err) }) AfterEach(func() { if pv == nil { return } By(fmt.Sprintf("Clean PV %s", pv.Name)) err := config.client.CoreV1().PersistentVolumes().Delete(pv.Name, &metav1.DeleteOptions{}) framework.ExpectNoError(err) }) It("all pods should be running", func() { var ( pvc   *v1.PersistentVolumeClaim pods  = map[string]*v1.Pod{} count = 50 err   error ) pvc = framework.MakePersistentVolumeClaim(makeLocalPVCConfig(config, DirectoryLocalVolumeType), config.ns) By(fmt.Sprintf("Create a PVC %s", pvc.Name)) pvc, err = framework.CreatePVC(config.client, config.ns, pvc) framework.ExpectNoError(err) By(fmt.Sprintf("Create %d pods to use this PVC", count)) for i := 0; i < count; i++ { pod := framework.MakeSecPod(config.ns, []*v1.PersistentVolumeClaim{pvc}, false, "", false, false, selinuxLabel, nil) pod, err := config.client.CoreV1().Pods(config.ns).Create(pod) Expect(err).NotTo(HaveOccurred()) pods[pod.Name] = pod } By("Wait for all pods are running") err = wait.PollImmediate(time.Second, 5*time.Minute, func() (done bool, err error) { podsList, err := config.client.CoreV1().Pods(config.ns).List(metav1.ListOptions{}) if err != nil { return false, err } runningPods := 0 for _, pod := range podsList.Items { switch pod.Status.Phase { case v1.PodRunning: runningPods++ } } return runningPods == count, nil }) Expect(err).ToNot(HaveOccurred()) }) }) </ins> }) func deletePodAndPVCs(config *localTestConfig, pod *v1.Pod) error {

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : New test case to cover scenario in Why is this needed: Prevent this issue happening again.
/assign /sig storage
Code change:
if fail && err == nil { t.Errorf("expecting failure, but got no err") } <del> if attachID != id && !fail { t.Errorf("expecting attachID %v, got %v", id, attachID) </del> <ins> if attachID != "" { t.Errorf("expecting empty attachID, got %v", attachID) </ins> } <del> }(tc.spec, tc.attachID, tc.nodeName, tc.shouldFail) </del> <ins> }(tc.spec, tc.nodeName, tc.shouldFail) </ins> var status storage.VolumeAttachmentStatus if tc.injectAttacherError {

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!--What happened: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/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
/remove-lifecycle stale
Code change:
Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

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:
Code change:
Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

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: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: [TODO] Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig node These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
Code change:
Labels:    map[string]string{"pod": name}, Resources: defaultPodRes, }) <del> // Setting grace period to zero. Otherwise, we may never see the actual deletion // of the pods in integration tests. </del> pod.Spec.TerminationGracePeriodSeconds = &grace return pod }

Related discussion:
text: Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: /sig scheduling
/assign
any progress on this one?
I was working on it and tried to find the root cause. I will give my solution within this week
Another one
Still happening cc
/assign
/close dupe
Closing this issue. <detailsIn response to : /close dupe 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:
Subsystem:         KubeletSubsystem, Name:              LastKnownGoodConfigKey, Help:              "The config source the node will fall back to when it encounters certain errors. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

Related discussion:
text: This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/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]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Code change:
// // // <del> // // </del> // This must be line #50. var _ = ginkgo.Describe("framework", func() {

Related discussion:
text: pull-kubernetes-unit Probably since it was merged in The test checks output from the E2E framework and sometimes some extra log output shows up that isn't expected: No response /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
/assign