jiebi/CodeConvo huggingface dataset:
Code change:
<ins> /* Copyright 2023 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package service import "context" /* Copied from: k8s.io/apiserver/pkg/storage/value/encrypt/envelope/kmsv2 */ // Service allows encrypting and decrypting data using an external Key Management Service. type Service interface { // Decrypt a given bytearray to obtain the original data as bytes. Decrypt(ctx context.Context, uid string, req *DecryptRequest) ([]byte, error) // Encrypt bytes to a ciphertext. Encrypt(ctx context.Context, uid string, data []byte) (*EncryptResponse, error) // Status returns the status of the KMS. Status(ctx context.Context) (*StatusResponse, error) } // EncryptResponse is the response from the Envelope service when encrypting data. type EncryptResponse struct { Ciphertext  []byte KeyID       string Annotations map[string][]byte } // DecryptRequest is the request to the Envelope service when decrypting data. type DecryptRequest struct { Ciphertext  []byte KeyID       string Annotations map[string][]byte } // StatusResponse is the response from the Envelope service when getting the status of the service. type StatusResponse struct { Version string Healthz string KeyID   string } </ins>

Related discussion:
text: I would implement that in terms of the interface so that it can be used both in testing (via a local key) and in real code (by delegating to a HSM).
Hi bug-triage team member for 1.27 here. This issue is still open but has had no recent activity, and no active PRs. Is everything on track for the Code Freeze in March 14th? Thank you!
/milestone clear
Could be closed, right? :)
We still need metrics and tracing support for the reference implementation (though it is all a lot less important now).
/retitle [KMSv2] Add metrics and tracing in for plugins
This is duplicate of /close
Closing this issue. <detailsIn response to : This is duplicate of 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:
apps "k8s.io/api/apps/v1" "k8s.io/api/core/v1" <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: a cluster, And node1 with resource 1 DaemonSet, request resource 4 run , There is no pod created. resource to the node: run , There is still no pod created. What you expected to happen: In step 5, There is one pod created. How to reproduce it (as minimally and precisely as possible): see above description Anything else we need to know?: Environment: Kubernetes version (use ):1.10.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):CentOS7 Kernel (e.g. ): Install tools: Others: /sig app
xref
Thanks! is not work here! Because: DaemonSetsController didn't watch the changes.(we use to updateNode.) we restart kubelet, The DaemonSetsController watch the changes, but it seems that the node info is not updated, and still failed to create pod:
I found it is a bug here, ignore the changes. I made a fix , PTAL! Thanks!
Any workarounds for old cluster versions? Up: looks like in my case helped but after some delay.
, which version of k8s are you using? If it's sunset, you have to merge the pr yourself :). I think restart kubelet trigger delete/add to make sure it sync .
Sorry, I didn't say
I think we still support 1.12 for now :) let's cherry pick it if not and wait for next 1.12 release.
Code change:
cmds.AddCommand(NewCmdPlugin(f, in, out, err)) cmds.AddCommand(NewCmdVersion(f, out)) cmds.AddCommand(NewCmdApiVersions(f, out)) <ins> cmds.AddCommand(NewCmdApiResources(f, out)) </ins> cmds.AddCommand(NewCmdOptions(out)) return cmds

Related discussion:
text: As the RBAC role need to be related to resources. I think we could use a command to get the supported resources. ref to
This would be cool.
I thought we a command that listed resources in the discover doc a long time ago.
is just the versions, but principle is the same. We want to list all the types, their resources, and tie that back to "explain".
What's the best way to determine this information currently? I'm having difficulty figuring out the exact set of permissions (and how they would be written in an RBAC role) for any given kubectl command. The documentation for this right now is split across multiple places and certain things are not explained at all. Specifically, it's difficult to determine which "API verb" is used for which operations. Take as an example. It's unclear if the way to allow this is to use the "proxy" subresource of a pod or service with "get"/"create"/etc. verbs, or to use the "proxy" verb with the resource (pod, service) directly. is a similar case. The almost works for this purpose, but it's still difficult. Operations for a given resource are grouped into categories like write, read, status, and proxy, but these things don't obviously correlate with API verbs. Again, proxy is especially confusing as there is no mention of a proxy "verb". The API operations are only shown using their HTTP verbs. One thing that could help on this document would be a section on the right column under "kubectl command" that shows exactly the rule needed in an RBAC role to allow this command via kubectl. And even then, that assumes an exact 1-to-1 mapping between API endpoints and kubectl commands, which I doubt is always the case. (For example, port fowarding to a pod seems to require both a GET on the pod resource and a CREATE on a port forward subresource.) There also needs to be better documentation about how this information could have been determined in the first place. I've resorted to manually looking through API requests made with but even then it's difficult to figure out. Amusingly, I was the one who wrote which is referenced in the original issue description (as well as the table explaining verbs in ).
Code change:
cmds.AddCommand(NewCmdPlugin(f, in, out, err)) cmds.AddCommand(NewCmdVersion(f, out)) cmds.AddCommand(NewCmdApiVersions(f, out)) <ins> cmds.AddCommand(NewCmdApiResources(f, out)) </ins> cmds.AddCommand(NewCmdOptions(out)) return cmds

Related discussion:
text: tl;dr: It's too difficult right now to go from "I want a user to be able to run " to "here is the RBAC rule to use for that" for any case where there isn't a specific example shown in the docs.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
It seem that relative PR stop updated. If this issue still valuable, i will help fix it
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
name: "TestPlugin1", inj:  injectedResult{FilterStatus: int(framework.Error)}, }, { name: "TestPlugin2", inj:  injectedResult{FilterStatus: int(framework.Error)},

Related discussion:
text: changed the default behavior of scheduler framework's - from stopping at the first failed filter to always running all filters. This change breaks Cluster Autoscaler at scale. Cluster Autoscaler imports the scheduler framework to simulate filters on artificial nodes. In a (pretty common) one-pod-per-node scenario, the number of calls is ~quadratic wrt. the number of nodes needed for unschedulable pods - it can be a lot of calls. Before , in such scenario the vast majority of calls would stop at failing Fit or NodeAffinity filters, and not run the rest of them (e.g. PV-related filters). After the change, every call to runs all filters, which completely breaks Cluster Autoscaler at scale (an example scenario of 300 1-pod-per-node pods and 200 node groups takes 10min in 1.24, and ~50s in <1.22). Can we get the old behavior back? Or re-introduce the config option so that Cluster Autoscaler can set it accordingly? Ideally, we'd also like to get this backported as far as possible (the change was introduced in 1.24).
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 scheduling
This seems to be a regression. I would be interested in adding a toggle flag that allows one to toggle on that behavior if this was done on purpose.
That PR wasn't supposed to change the behavior actually. Scheduler is always defaulted to stop upon the first Filter failure, and it's just we offered an option to continue go through other Filter plugins upon failures, and that option was removed recently. Let me check the code to see if there is a regression.
When removed the following changes: It should have kept . I will submit a fix along with test, and backport to 1.24, 1.25, 1.26. Thanks for reporting!
Code change:
name: "TestPlugin1", inj:  injectedResult{FilterStatus: int(framework.Error)}, }, { name: "TestPlugin2", inj:  injectedResult{FilterStatus: int(framework.Error)},

Related discussion:
text: cc /assign /kind bug /kind regression /priority critical-urgent /triage/accepted
Thanks Kuba, this is indeed a regression on the scheduler end.
/open for patches
/re-open /reopen
Reopened this issue. <detailsIn response to : /re-open /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
Thanks for the reporting, and thanks for the fix.
Really sorry about this regression, and hope not to happen again. I think there's no e2e tests between kubernetes scheduler and cluster-autoscaler, so can we also have testcases of pods unschedulable in scheduling perf-test, maybe this can also help to prevent this happening again. UT benchmark test also makes sense, but it's not graphical.
Thanks for the quick fix! Unfortunately I'm afraid this kind of issue would only be caught in a large-scale test scenario, which is not cheap to run continuously.
For this particular issue, UT ( in the PR) is able to catch it. And hence doesn't need to be that complicated to test with cluster-autoscaler. However, standing from a broader angle, why we didn't catch the regression in perf test is b/c the triggering actor is unschedulable Pods, instead of schedulable Pods (which are the happy path most perf tests covered). So going forward, I'd like to see more perf tests to mixin unschedulable Pods, and hence more likely to surface this kind of issue. (we have preemptio preemption test suite but doesn't seem adequate)
This is not for the particular issue, but keeping an eye on whether there's any performance degradation between two kubernetes components, like we do for scheduling performance. but it's actually out of the scope of scheduler. I'll add it as one of the goals of
Actually, the schedulerperf has a test case . And, the schedulerperf collects the metric (), which has the label in it (). But, the problem is currently we don't distinguish the metric values by label on each data; we just collect/aggregate it regardless the label.
Code change:
name: "TestPlugin1", inj:  injectedResult{FilterStatus: int(framework.Error)}, }, { name: "TestPlugin2", inj:  injectedResult{FilterStatus: int(framework.Error)},

Related discussion:
text: (We can distinguish the metric values by any labels in the schedulerperf as we do in the metric ()) I'd say just distinguishing the happy path and unhappy path with label in metric should be enough to observe the particular performance degradation in the unhappy path.
could you help share the perf-dash link where this metric () is exposed?
Hm, cannot see any scheduler metrics result from the current perf-dash I see some configuration that seems to be to parse the schedulerperf result file though. https://perf- TBH, I haven't visited the perf-dash so much, so not sure whether it's not working for a long time, or got broken recently. Also, another thing, I noticed the perf-dash doesn't show all test cases. All test cases after haven't been executed.
So... probably, something wrong happens in  job (probably in the test case) and the schedulerperf is failing. The schedulerperf doesn't make the result file when fails, so I'm guessing that's why we cannot see any scheduler metrics results from the perf-dash. Okay, I found it. Let me open another issue for this.
cc is this actually a regression, and is it resolved yet?
It's resolved by , and also cherry-picked to 1.24.x ~ 1.26.x. /close
Closing this issue. <detailsIn response to : It's resolved by , and also cherry-picked to 1.24.x ~ 1.26.x. 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:
config.CloudProviderBackoffDuration = backoffDurationDefault } <del> // Do not add master nodes to standard LB by default. if config.ExcludeMasterFromStandardLB == nil { config.ExcludeMasterFromStandardLB = &defaultExcludeMasterFromStandardLB </del> <ins> if strings.EqualFold(config.LoadBalancerSku, loadBalancerSkuStandard) { // Do not add master nodes to standard LB by default. if config.ExcludeMasterFromStandardLB == nil { config.ExcludeMasterFromStandardLB = &defaultExcludeMasterFromStandardLB } // Enable outbound SNAT by default. if config.DisableOutboundSNAT == nil { config.DisableOutboundSNAT = &defaultDisableOutboundSNAT } } else { if config.DisableOutboundSNAT != nil && *config.DisableOutboundSNAT { return nil, fmt.Errorf("disableOutboundSNAT should only set when loadBalancerSku is standard") } </ins> } azClientConfig := &azClientConfig{

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: is the recommended way to configure the outbound networks together with Azure standard loadbalancer (SLB). However, for load balancer rules are disabled by default. That means all frontend IPs would be used as the SNAT IPs for virtual machines, according to . This would introduce troubles for various security scenarios, as there's no way to get a stable list of egress IPs. Azure cloud provider should support this scenario, and disable the outbound SNAT when outbound rules are configured by provisioning tools. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /kind bug /sig azure /priority critical-urgent
Code change:
} } <del> func TestValidateCustomResource(t *testing.T) { type args struct { schema apiextensions.JSONSchemaProps object interface{} </del> <ins> func stripIntOrStringType(x interface{}) interface{} { switch x := x.(type) { case map[string]interface{}: if t, found := x["type"]; found { switch t := t.(type) { case []interface{}: if len(t) == 2 && t[0] == "integer" && t[1] == "string" && x["x-kubernetes-int-or-string"] == true { delete(x, "type") } } } for k := range x { x[k] = stripIntOrStringType(x[k]) } return x case []interface{}: for i := range x { x[i] = stripIntOrStringType(x[i]) } return x default: return x </ins> } <ins> } func TestValidateCustomResource(t *testing.T) { </ins> tests := []struct { <del> name    string args    args wantErr bool </del> <ins> name           string schema         apiextensions.JSONSchemaProps objects        []interface{} failingObjects []interface{} </ins> }{ <del> // TODO: make more complete {"!nullable against non-null", args{ apiextensions.JSONSchemaProps{ </del> <ins> {name: "!nullable", schema: apiextensions.JSONSchemaProps{ </ins> Properties: map[string]apiextensions.JSONSchemaProps{ "field": { Type:     "object",

Related discussion:
text: The server-side validation does not check the type of values with . Create a CRD like: Then create a CR: It is not rejected, but should because must not be a boolean.
Code change:
{d: 8 * 24 * time.Hour, want: "8d"}, {d: 8*24*time.Hour + 23*time.Hour, want: "8d"}, {d: 2*365*24*time.Hour - time.Millisecond, want: "729d"}, <del> {d: 2 * 365 * 24 * time.Hour, want: "2y0d"}, {d: 2*365*24*time.Hour + 23*time.Hour, want: "2y0d"}, {d: 3 * 365 * 24 * time.Hour, want: "3y0d"}, </del> <ins> {d: 2 * 365 * 24 * time.Hour, want: "2y"}, {d: 2*365*24*time.Hour + 23*time.Hour, want: "2y"}, {d: 2*365*24*time.Hour + 23*time.Hour + 59*time.Minute, want: "2y"}, {d: 2*365*24*time.Hour + 24*time.Hour - time.Millisecond, want: "2y"}, {d: 2*365*24*time.Hour + 24*time.Hour, want: "2y1d"}, {d: 3 * 365 * 24 * time.Hour, want: "3y"}, {d: 4 * 365 * 24 * time.Hour, want: "4y"}, {d: 5 * 365 * 24 * time.Hour, want: "5y"}, {d: 6 * 365 * 24 * time.Hour, want: "6y"}, {d: 7 * 365 * 24 * time.Hour, want: "7y"}, </ins> {d: 8*365*24*time.Hour - time.Millisecond, want: "7y364d"}, {d: 8 * 365 * 24 * time.Hour, want: "8y"}, {d: 8*365*24*time.Hour + 364*24*time.Hour, want: "8y"},

Related discussion:
text: What happened: When the duration is exactly 2 years or 3 years, human readable duration is returned as or . But when the duration is exactly 4 years, 5 years, etc, the human readable duration is returned as , , etc. What you expected to happen: The format of an exact year should be consistent. Remove when duration is an exact year: should be should be Check other years... 4, 5, 6, 7... not sure if they also have the problem. How to reproduce it (as minimally and precisely as possible): Because this is time-dependent, it can be difficult to reproduce via the CLI, but you can see the problem illustrated in which shows the current behavior: The and test cases should be changed to want and , and the code should be changed to make that pass. Anything else we need to know?: Note, this is not a problem when the duration is exactly 1 year because the human readable duration is still shown in days. So nothing needs to change to handle the case of exactly 1 year. Environment: Kubernetes version (use ): 1.18 Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a
/sig api-machinery
/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 : /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
Could I pick this up as my first issue?
Absolutely. Just use to assign it to yourself.
Also I just updated the issue description. Check the other exact years 4, 5, 6, 7 because they might also have the problem, I can't remember. I know 8 and beyond don't have the problem because it just stops showing days after 8 years.
/assign bitscuit
might recall a related PR?
Code change:
{d: 8 * 24 * time.Hour, want: "8d"}, {d: 8*24*time.Hour + 23*time.Hour, want: "8d"}, {d: 2*365*24*time.Hour - time.Millisecond, want: "729d"}, <del> {d: 2 * 365 * 24 * time.Hour, want: "2y0d"}, {d: 2*365*24*time.Hour + 23*time.Hour, want: "2y0d"}, {d: 3 * 365 * 24 * time.Hour, want: "3y0d"}, </del> <ins> {d: 2 * 365 * 24 * time.Hour, want: "2y"}, {d: 2*365*24*time.Hour + 23*time.Hour, want: "2y"}, {d: 2*365*24*time.Hour + 23*time.Hour + 59*time.Minute, want: "2y"}, {d: 2*365*24*time.Hour + 24*time.Hour - time.Millisecond, want: "2y"}, {d: 2*365*24*time.Hour + 24*time.Hour, want: "2y1d"}, {d: 3 * 365 * 24 * time.Hour, want: "3y"}, {d: 4 * 365 * 24 * time.Hour, want: "4y"}, {d: 5 * 365 * 24 * time.Hour, want: "5y"}, {d: 6 * 365 * 24 * time.Hour, want: "6y"}, {d: 7 * 365 * 24 * time.Hour, want: "7y"}, </ins> {d: 8*365*24*time.Hour - time.Millisecond, want: "7y364d"}, {d: 8 * 365 * 24 * time.Hour, want: "8y"}, {d: 8*365*24*time.Hour + 364*24*time.Hour, want: "8y"},

Related discussion:
text: (also, I have to leave the pedantic note: a year isn't always 365 days, so it's surprising to me to see the abbreviation exists at all)
I can't find it. Maybe I was remembering
Yeah it was probably that one. At first I had the tests and the fix. But it sat for a while. I changed it to just the tests of existing behavior so it could be approved more easily. Then I made this issue for the fix but decided it would probably be a good first time issue for someone instead of me doing it.
so should leap years be considered by the code?
There's no way to know how long a year is without knowing the date, so it's not a good unit--in the abstract, there's no way to know if it's a leap year or not. The go language deliberately omits it IIRC. Henry Li <:
What's the intention of HumanDuration? From what I've seen, it is just an approximation of a timestamp solely for humans to understand, so assuming 365 days per year sounds about right to me. This issue is about consistency though, so it could be solved the other way. Instead of abbreviating when it's an exact year (2y, 3y, etc.), exact years could just all have 0d (2y0d, 3y0d, etc.)
I think it is just used for a ballpark duration. It loses accuracy as the duration increases anyway because it changes the units. I guess my intention for opening the issue was to make it consistent with itself. For example it doesn't say 2d0h or 2h0m, so it should not say 2y0d.
(FTR I agree that Xy0d looks worse than Xy.) Brian Pursley <:
Hi I have made the required changes. Shall I raise the PR if you haven't started working in it ?
already assigned it, so I think it would be good to let him submit the PR, unless he unassigns or does not submit a PR in a reasonable amount of time.
Thanks I was planning on submitting the PR over the weekend
Hello, I am a first timer in open source contribution community. I think I made the required changes for that issue. However, I don't know how assignment rules work.
Code change:
# Wait for last batch of jobs kube::util::wait-for-jobs || { <del> echo -e "${color_red}Some commands failed.${color_norm}" >&2 </del> <ins> code=$? echo -e "${color_red}Failed to create firewall rule.${color_norm}" >&2 exit $code </ins> } }

Related discussion:
text: Kubernetes e2e suite [It] [sig-network] Firewall rule should have correct firewall rules for e2e cluster See also a similar cluster with the same test failing: /kind failing-test /kind flake /sig network
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