jiebi/CodeConvo huggingface dataset:
Change:
glog.Warning("Channel nodeCIDRUpdateChannel was unexpectedly closed") return } <del> if err := ca.updateCIDRAllocation(workItem); err != nil { if ca.canRetry(workItem) { time.AfterFunc(updateRetryTimeout, func() { </del> <ins> if err := ca.updateCIDRAllocation(workItem); err == nil { glog.V(3).Infof("Updated CIDR for %q", workItem) ca.removeNodeFromProcessing(workItem) } else { glog.Errorf("Error updating CIDR for %q: %v", workItem, err) if canRetry, timeout := ca.retryParams(workItem); canRetry { glog.V(2).Infof("Retrying update for %q after %v", workItem, timeout) time.AfterFunc(timeout, func() { </ins> // Requeue the failed node for update again. ca.nodeUpdateChannel <- workItem }) continue } <ins> glog.Errorf("Exceeded retry count for %q, dropping from queue", workItem) </ins> } <del> ca.removeNodeFromProcessing(workItem) </del> case <-stopChan: return }

Discussion:
/kind bug /sig network What happened: Networking tight loop causing GCP Cloud rate limiting to kick in. Causing tests to fail. Suspected call stack: Looks like it could be the root cause of these test failures here: https://k8s- These storage tests are hitting rate limit on the cloud api when trying to detach/delete disks. However, we have exponential backoff for all these functions. But the rate limiting from an external source is affecting the tests. See logs snippet: Note: These logs span exactly 1 minute. Try grepping "rateLimit" or "CIDRNotAvailable" -also note that the CIDRNotAvailable error messages are probably not verbose enough as they do not pinpoint what the actual error is, you can only associate them by correlation in timing and then looking at the code. Shorter snippet from above log file to demonstrate: since this is running on hundreds of nodes hitting this API call should involve some sort of exponential backoff as well as jitter. /cc /assign
/assign
/assign
/sig cloud-provider /sig gcp /milestone v1.12 (since is marked as v1.12)
may we have a priority on this since Code Freeze is next week? :)
Quick question, are we using the default API rate limits quota for scalability projects?
I will defer to for priority because he probably has the most context on how serious this is and what it could affect
Which rate limit are you referring to? (I don't remember us changing it any time) Btw - this is the project being used for that job -
I put up a patch for adding exponential retry
Gentle reminder that for this to be considered for 1.12 past Code Freeze, which is next week, it must have a status/critical-urgent label. I see this is being actively worked on
Change:
framework.ExpectEqual(foundCreatedEvent, false, "should not have found test event after deletion") }) <del> ginkgo.It("should delete a collection of events", func() { </del> <ins> /* Release : v1.19 Testname: Event, delete a collection Description: A set of events is created with a label selector which MUST be found when listed. The set of events is deleted and MUST NOT show up when listed by its label selector. */ framework.ConformanceIt("should delete a collection of events", func() { </ins> eventTestNames := []string{"test-event-1", "test-event-2", "test-event-3"} ginkgo.By("Create set of events")

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: 6 July 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still an endpoint which is untested. a set of 3 Events with a static label within a Namespace. that all 3 Events with the label in the Namespaces are created. the set of Namespaced Events with a label via DeleteCollection. that all Events with the label have been deleted. Discover useragents: List endpoints hit by the test: Display endpoint coverage change: Two other endpoints tested here have tests in progress to conformance already. If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
During Conformance Meeting: Is there a way to write this test so it is resource agnostic? If we are just changing the resource... can be parameterize the resource-type
/assign
GitHub didn't allow me to assign the following users: heyste. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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 PR Merge and soaking
Reopened this issue. <detailsIn response to : /reopen PR Merge and soaking 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
Change:
"secure, no roots, custom dial": { TLSConfig:   &tls.Config{InsecureSkipVerify: false}, Dial:        d.DialContext, <del> ExpectError: "unknown authority", </del> <ins> ExpectError: "unknown authority|not trusted", </ins> }, "secure with roots, custom dial": { TLSConfig: &tls.Config{InsecureSkipVerify: false, RootCAs: roots},

Discussion:
unit tests since switching to go1.18 No response No response Weirdly, the test is passing in CI () and failing locally /sig api-machinery auth testing
seems related Jordan, are you using mac ?
yes, though the description in that issue seems to be not just test-only changes to the errors received from invalid certificates (which is what I saw), but actual certificates that previously validated
marking as release blocker until it is determined that go1.18 is not rejecting valid certificates
this needs an assignee and a reproducer we can file as an upstream issue for golang to ask why previously valid certificates now fail validation
marking critical until root-caused and determined whether this is prod-impacting, since (in my opinion) this should block rc0
On linux it works fine: on MacOS, it fails:
Looks like the change in golang that broke the scenario was:
if the only impact is a different failure message on an already-invalid certificate, I don't care and we can update the test to accept either message is what makes me wonder what previously-accepted certificates are now failing
reproducer test case here. this one has no issues under go 1.17 and fails with go 1.18 (stripped down version of ) : :
the new error message is minted here: i suspect it is related to: So essentially this seems to be something that may hit in our case. right?
yeah, if this is scoped to just darwin clients, and only ones using system roots, that greatly narrows the impact
Asked on gophers slack -
xref:
opened to tolerate the additional errors discussion in indicates the tightened validation is very bounded (darwin-only, so clients-only, system roots only), and certificates issued by public CAs would be expected to pass this validation dropping release-blocking label and priority to important-soon, but should still make it into 1.24 to make unit tests pass locally
Change:
case p == test.podPath && m == "GET": body := objBody(codec, test.pod) return &http.Response{StatusCode: 200, Header: defaultHeader(), Body: body}, nil <ins> case p == test.shortPodPath && m == "GET": body := objBody(codec, test.pod) return &http.Response{StatusCode: 200, Header: defaultHeader(), Body: body}, nil </ins> default: // Ensures no GET is performed when deleting by name t.Errorf("%s: unexpected request: %s %#vn%#v", test.name, req.Method, req.URL, req)

Discussion:
I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.
Change:
createBatchPodWithRateControl(f, restartNeverPods, podCreationInterval) defer deletePodsSync(f, restartNeverPods) <del> completedPods := waitForPods(f, podCountRestartNever, time.Minute) </del> <ins> completedPods := waitForPods(f, podCountRestartNever, startTimeout) </ins> if len(completedPods) < podCountRestartNever { framework.Failf("Failed to run sufficient restartNever pods, got %d but expected %d", len(completedPods), podCountRestartNever) }

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
return nil, err } <ins> requestInfo := getRequestInfoFromContext(ctx) </ins> uid := string(uuid.NewUUID()) <del> klog.V(6).InfoS("encrypting content using envelope service", "uid", uid, "key", string(dataCtx.AuthenticatedData())) </del> <ins> klog.V(6).InfoS("encrypting content using envelope service", "uid", uid, "key", string(dataCtx.AuthenticatedData()), "group", requestInfo.APIGroup, "version", requestInfo.APIVersion, "resource", requestInfo.Resource, "subresource", requestInfo.Subresource, "verb", requestInfo.Verb, "namespace", requestInfo.Namespace, "name", requestInfo.Name) </ins> resp, err := t.envelopeService.Encrypt(ctx, uid, newKey) if err != nil { return nil, fmt.Errorf("failed to encrypt DEK, error: %w", err)

Discussion:
Add additional logging at level that associates UID with the metadata from the request. xref: /sig auth
/triage accepted
/milestone v1.26
Mind if I take a look at this? /assign
Hello I am wondering how's this coming along. Is there anything I can help with?
Sorry. I got a bit occupied with a different project.. Will have a PR opened for this for review tomorrow.. I am trying to find a way to inject the Verbs into log. But haven't found the right way to include that into the context.. Any suggestion on what can be done?
any suggestion on what is the best way to get the additional metadata for verbs into this log? Move that info across using ?
Hello , bug triage team here, just wanted to touch base with you for updates on this ticket. Thanks!
Thanks! This is being worked on and is still on track for .
There is a Pull request opened on this already as well. But Waiting on some clarification to see if that needs additional changes.
/reopen /assign /unassign
Reopened this issue. <detailsIn response to : /reopen /assign /unassign 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
/milestone v1.27
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 Bug Triage Team for v1.27 here o/ Just wanted to touch base with you for updates on this ticket. Thanks!
I am not working on this anymore Carlos. This was re-assigned
This is tracked for . I've linked the PR.
Change:
}, "mountPropagation": { "$ref": "v1.MountPropagationMode", <del> "description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is alpha in 1.8 and can be reworked or removed in a future release." </del> <ins> "description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is beta in 1.10." </ins> } } },

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
I push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
if username != "" { wc.SecurityContext.RunAsUsername = username } <del> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.WindowsGMSA) && effectiveSc.WindowsOptions != nil && </del> <ins> if effectiveSc.WindowsOptions != nil && </ins> effectiveSc.WindowsOptions.GMSACredentialSpec != nil { wc.SecurityContext.CredentialSpec = *effectiveSc.WindowsOptions.GMSACredentialSpec }

Discussion:
Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /sig windows /milestone v1.20 /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 : Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /milestone v1.20 /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
/triage accepted
Hi, how can i help with that?
Delete the codes related to these two feature gates, because they have been GA and are enabled by default
Yup, feel free to assign the issue to yourselft and then remove the features gates from the file listed above and any other places they are used in code. Thanks!
Hey, can i take this up ?
/assign
It seems that proposed it first. You can communicate with him before you start.
ok sure
/assign
Hi, Sorry by delay, but i cant push the issue branch and receive: fatal: unable to access '': The requested URL returned error: 403 I already fill the form to contriburter. Any sugestion? Regards
Before you start, you can read
i already assing to CLA and make a new branch issue-. But when i push the branch my permission is denny. any tips? Tkz
Try forking the kubernetes/kubernetes repository and then creating the pull request from a branch in your personal github repository.
Tkz, I create a PR, but i received: cla/linuxfoundation — commit missing GitHub user but i already do it. Whats is wrong?
Ok, i found the error. My name in git was wrong. Sorry, Im waiting the result for PR. Tkz
Now, i waiting for
Hi everyone, Is normal waiting this itens, or I must provide then? Tkz
Ok, Em ter., 20 de out.

de 2020 às 15:47, Mark Rossetti < : Doutor em Ciência da Computação na UNICAMP
When your code is ready, you can pull a pr from your own repo to kubernetes' repo~~ Remember to read the connection I posted earlier and the sub-connections inside.
Hi , we already past the code freeze for v1.20 and the release is due next week. At this point in time, we are considering only changes which are release blocking. Hence, I am removing this from the v1.20 milestone. Please feel to ping us on if you feel otherwise. /milestone clear
Hey Is there anything that can be done here?
Hi ! can I take this? anything required?
Hi, yes of course. Nothing to relate. Em ter., 19 de jan. de 2021 às 13:24, coderfornow <: Doutor em Ciência da Computação na UNICAMP
/assign
Change:
ginkgo.By("Waiting for a default service account to be provisioned in namespace") err = WaitForDefaultServiceAccountInNamespace(f.ClientSet, namespace.Name) ExpectNoError(err) <ins> ginkgo.By("Waiting for kube-root-ca.crt to be provisioned in namespace") err = WaitForKubeRootCAInNamespace(f.ClientSet, namespace.Name) ExpectNoError(err) </ins> } else { Logf("Skipping waiting for service account") }

Discussion:
Originally posted by in
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 testing /cc
/hold I have a subtly different fix in :)
Oh wait, this is an issue. Yay, thanks :). Fixed in
Change:
return deviceMountPath, nil } <del> func (c *csiAttacher) MountDevice(spec *volume.Spec, devicePath string, deviceMountPath string) error { </del> <ins> func (c *csiAttacher) MountDevice(spec *volume.Spec, devicePath string, deviceMountPath string) (err error) { </ins> glog.V(4).Infof(log("attacher.MountDevice(%s, %s)", devicePath, deviceMountPath)) mounted, err := isDirMounted(c.plugin, deviceMountPath)

Discussion:
/kind bug /sig storage What happened: When using a CSI driver that does not support NODESTAGE, I can see orphan json files in that are never cleaned up. What you expected to happen: No orphan file /assign
Change:
Logf("Error getting pods in namespace '%s': %v", ns, err) return false, nil } <del> nOk, replicaOk := int32(0), int32(0) </del> <ins> nOk := int32(0) </ins> badPods = []api.Pod{} desiredPods = len(podList.Items) for _, pod := range podList.Items {

Discussion:
The logic to account for all pods being ready is incorrectly counting some pods as being controlled by a replication controller. This is causing the 1.3-1.5 upgrade tests to fail. See https://k8s- as an example. Since , the pre-flight checks fail and the rest of the tests never run. I think this was exposed by which changed some things from ReplicationControllers to Deployments. There's a pod being created by a deployment that also matches the selector of a replication controller, and is therefore being incorrectly counted by cc