jiebi/CodeConvo huggingface dataset:
Change:
// the specified LimitRange.  The pod may be modified to apply default resource // requirements if not specified, and enumerated on the LimitRange func PodLimitFunc(limitRange *api.LimitRange, pod *api.Pod) error { <ins> var errs []error </ins> defaultResources := defaultContainerResourceRequirements(limitRange) mergePodResourceRequirements(pod, &defaultResources) for i := range limitRange.Spec.Limits { limit := limitRange.Spec.Limits[i] limitType := limit.Type // enforce container limits if limitType == api.LimitTypeContainer { for j := range pod.Spec.Containers { container := &pod.Spec.Containers[j] for k, v := range limit.Min { if err := minConstraint(limitType, k, v, container.Resources.Requests, container.Resources.Limits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } for k, v := range limit.Max { if err := maxConstraint(limitType, k, v, container.Resources.Requests, container.Resources.Limits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } for k, v := range limit.MaxLimitRequestRatio { if err := limitRequestRatioConstraint(limitType, k, v, container.Resources.Requests, container.Resources.Limits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } }

Discussion:
When a resource violates the limitrange, both for cpu and memory, only one error will be returned at a time. That means when a user is creating such a resource, first it will fail and return something like , them user may edit the cpu usage and create again, then fail again and get . It seem admission controls want to reject the request as fast as possible, if error occurs. But in this case, it may give users a bad experience. Would it be better to aggregate all errors and return them at one time. Also, the error message may cause misunderstanding. , it means the resource requested is 3, it may also cause a confusion that it is limited to 3.
Closing since it's fixed
Change:
"net/http/httptest" "reflect" "testing" <ins> "time" </ins> "github.com/gogo/protobuf/proto" "github.com/googleapis/gnostic/OpenAPIv2"

Discussion:
<!-- 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: With client-go v0.17.0, I observed many "Throttling request" when DiscoveryClient is used to get API group resources from API server. This didn't happen with client-go kubernetes-1.16.0. It looks like originally this kind of discovery requests are not throttled because no rate limiter provided and QPS == 0. But with rate limiter is always set if nil rate limiter is provided. is particularly suspicious because it is always true because DefaultQPS is nonzero. What you expected to happen: Discovery requests should not be throttled as before. How to reproduce it (as minimally and precisely as possible): Create DiscoveryClient and then call with it. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
The NewTokenBucketRateLimiter was via Always negotiate a decoder using ClientNegotiator /cc
To be clear, that was fixing a bug where the documented defaults for rate limiting were not taking effect. I don't think we should completely disable throttling until more of the server-side priority work is completed, but discovery is expected to be bursty, so I could see defaulting to a different amount in the discovery client constructor, similar to
Yeah, everyone must be rate limited. I think we could give discovery a big burst value.
opened
Change:
done # Run gazelle to update Go rules in BUILD files. <ins> # filter out known pkg-config error (see buildozer workaround below) # NOTE: the `|| exit "${PIPESTATUS[0]}"` is to ignore grep errors # while preserving the exit code of gazelle </ins> gazelle fix  -external=vendored  -mode=fix  -repo_root "${KUBE_ROOT}"  <del> "${KUBE_ROOT}" </del> <ins> "${KUBE_ROOT}"  2>&1 | grep -Ev "vendor/github.com/seccomp/libseccomp-golang/seccomp(_internal)?.go: pkg-config not supported: #cgo pkg-config: libseccomp" || (exit "${PIPESTATUS[0]}") </ins> # Run kazel to update the pkg-srcs and all-srcs rules as well as handle # Kubernetes code generators.

Discussion:
<!-- 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: Got the following error while trying to run : How to reproduce it (as minimally and precisely as possible): Ran this on a fresh install of ubuntu 19.04, Go 1.12.6, and bazel 0.26.1. Anything else we need to know?: Seems like the change might have been due to the update in vendored deps from ( ). Although this script is run in CI where it is working so may be some set of recommende pkg versions would help prevent this problem? Environment: Cloud provider or hardware configuration: OS (e.g: ): ubuntu 19.04 Kernel (e.g. ): 5.0.0-15-generic bazel: 0.26.1 Go: 1.12.6
Not sure who owns this... /sig testing
Seems like the errors are "warnings" and can be ignored? It seems that BUILD files are properly updated by update-bazel, And bazel builds do work properly... /cc
/sig release this is not a failure /retitle hack/update-bazel produces warnings there was some discussion on the original PR about filtering them out but nothing conclusive I'll file a PR to do that now.. /assign
aside: this is actually from :-) we're working around the lack of support because we only need it for this package and on all known systems we compile on so far it only needs the one link flag as previously specified in the cgo config.
filed
Glad to see it. The output message is so misleading that I have spent hours on this issue
sorry about that the output does say "error" but it's actually considered a non-fatal warning in the upstream code and doesn't cause the script (or build) to fail.
was merged before this discussion was resolved , so we kinda saw this coming. :/ Hopefully we can get the fix from in merged as quick as possible
/reopen we have a new a new occurrence with libipmctl
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
I have the same question. This output is a bit annoying.
We can update the script to handle this issue and suppress the warning. The previous PR is an example. On Thu, Apr 16, 2020, 12:14 AM <:
/assign
Change:
ginkgo.It("should have stable networking for Linux and Windows pods", func() { ginkgo.By("creating linux and windows pods") linuxPod := createTestPod(f, linuxBusyBoxImage, linuxOS) <ins> linuxPod = f.PodClient().CreateSync(linuxPod) </ins> windowsPod := createTestPod(f, windowsBusyBoximage, windowsOS) windowsPod.Spec.Containers[0].Args = []string{"test-webserver"} <ins> windowsPod = f.PodClient().CreateSync(windowsPod) </ins> ginkgo.By("checking connectivity to 8.8.8.8 53 (google.com) from Linux") assertConsistentConnectivity(f, linuxPod.ObjectMeta.Name, linuxOS, linuxCheck("8.8.8.8", 53))

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: All the v1.18 / master jobs in: Which test(s) are failing: [sig-windows] Hybrid cluster network for all supported CNIs should have stable networking for Linux and Windows pods Since when has it been failing: Since this was merged: Testgrid link: Reason for failure: Previously, we've centralized several images into agnhost, including test-webserver. The Hybrid cluster network test was using the test-webserver image, and was updated to use agnhost, but without properly making it so it behaves like test-webserver, resulting in a failing test. Anything else we need to know: /sig windows /sig testing /priority important-soon
Change:
// Search returns a list of events matching the specified object. func (c *FakeEvents) Search(scheme *runtime.Scheme, objOrRef runtime.Object) (*v1.EventList, error) { <del> action := core.NewRootListAction(eventsResource, eventsKind, metav1.ListOptions{}) </del> <ins> var action core.ListActionImpl </ins> if c.ns != "" { action = core.NewListAction(eventsResource, eventsKind, c.ns, metav1.ListOptions{}) <ins> } else { action = core.NewListAction(eventsResource, eventsKind, v1.NamespaceDefault, metav1.ListOptions{}) </ins> } obj, err := c.Fake.Invokes(action, &v1.EventList{}) if obj == nil {

Discussion:
Opening this issue based on what I ran into on with namespace as follows While unit testing the controller, we create a fake client and setup the controller to run using the client. This ends up creating a having the namespace set to When the call eventually reaches The action gets associated with a namespace only if the object has a namespace associated with it. Which in this will be Which will result in the error in to manage the event like does. In case if the namespace is set to Above is a test case that can easily simulate the issue in question. Referring back to the test under PR NA <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Change:
"claim-reference": { pod:    podWithClaimName, claims: []*resourcev1alpha2.ResourceClaim{allocatedClaim, otherClaim}, <ins> want: want{ reserve: result{ changes: change{ claim: func(claim *resourcev1alpha2.ResourceClaim) *resourcev1alpha2.ResourceClaim { if claim.Name == claimName { claim = claim.DeepCopy() claim.Status.ReservedFor = inUseClaim.Status.ReservedFor } return claim }, }, }, }, </ins> }, "claim-template": { pod:    podWithClaimTemplate, claims: []*resourcev1alpha2.ResourceClaim{allocatedClaim, otherClaim}, <ins> want: want{ reserve: result{ changes: change{ claim: func(claim *resourcev1alpha2.ResourceClaim) *resourcev1alpha2.ResourceClaim { if claim.Name == claimName { claim = claim.DeepCopy() claim.Status.ReservedFor = inUseClaim.Status.ReservedFor } return claim }, }, }, }, </ins> }, "missing-claim": { pod: podWithClaimTemplate,

Discussion:
Apply this patch: Then run: This fails with: Test should pass. See above. If there are N objects in claims.Items, then this loop for _, claim := range claims.Items { objects = append(objects, &claim) } is appending the same pointer N times, pointing at the final item in the list. Adding fixes that mistake, but then it makes the test fail. Something else about the test is buggy, but the bug was being masked by this bug. In the repro case I to the loop a few lines down, just for good measure, but that one is not causing a problem. The line by itself causes the test failure. HEAD N/A N/A N/A N/A N/A
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 /priority important-soon /cc Thanks for finding this and the detailed report
/assign
Can you help to fix this?
If we don't here from soonish, then I'll fix it myself.
Sorry, I've been busy with an office accident this week, if you want fix it, please take it
/assign
/unassign
Change:
}, metricsName: "scheduler_pending_pods", wants: ` <del> # HELP scheduler_pending_pods [ALPHA] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </del> <ins> # HELP scheduler_pending_pods [STABLE] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </ins> # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 30 scheduler_pending_pods{queue="backoff"} 20

Discussion:
I would like to propose the graduation of the following scheduler metrics from alpha to stable: These metrics have been stable for at least 15 months.
/sig scheduling /sig instrumentation
/cc
IIRC, the last addition to these metrics was the profile name label. I don't foresee need for new labels. I don't see many precedents for graduation in core components. are there any defined criteria for graduation?
As requested, the following is how long it has been since a change has been made to each of the requested metrics: - 2 years; last change was to migrate to the metrics stability framework - 17 months; last change was a renaming of the metric - 15 months; last change was a renaming of the metric - 17 months; last change was to add a label - 17 months; last change was to add a label
It's up to the component owners to commit to graduating these metrics, since the component owners own the metrics and therefore need to agree to support them in accordance to stability requirements. If you guys are okay with promoting these metrics, I don't see a reason, from an instrumentation side, why we would object to promotion.
+1 to graduation then. These metrics are very mature. Although, I'm not sure if all metrics already adhere to naming conventions. and don't have a unit suffix, but they are unit-less. Is that fine
is a gauge so it's fine, is a histogram so it's also fine.
I'm recently working with metrics, I'm glad to provide some help if no one has interest about it.
There is already an open PR for this.
Oh sorry, didn't notice about that. Forget it.
These graduations sound good to me, but I would be inclined to rename . I feel that the part of the metric is unnecessary. Having instead and keeping for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the text of the metric can be used to guide the users.
I agree that is rather confusing, so +1 to removing the prefix. The metric doesn't include retries, for example. We have a separate metric that includes retries: We need to rename that one eventually to e2e, but it can only be done after the existing one has been deprecated and deleted for a few releases. /triage accepted
/assign
/cc
The PR for this is ready to be reviewed:
Change:
} } <ins> func TestIdleShutdownRace(t *testing.T) { var wg sync.WaitGroup server, listen, serverErr := runServer(&wg) if serverErr != nil { t.Fatalf("Error initializing server: %s", serverErr) } conn, dialErr := net.Dial("tcp", listen) if dialErr != nil { t.Fatalf("Error dialing server: %s", dialErr) } spdyConn, spdyErr := NewConnection(conn, false) if spdyErr != nil { t.Fatalf("Error creating spdy connection: %s", spdyErr) } go spdyConn.Serve(NoOpStreamHandler) authenticated = true stream, err := spdyConn.CreateStream(http.Header{}, nil, false) if err != nil { t.Fatalf("Error creating stream: %v", err) } spdyConn.SetIdleTimeout(5 * time.Millisecond) go func() { time.Sleep(5 * time.Millisecond) stream.Reset() }() select { case <-spdyConn.CloseChan(): case <-time.After(20 * time.Millisecond): t.Fatal("Timed out waiting for idle connection closure") } closeErr := server.Close() if closeErr != nil { t.Fatalf("Error shutting down server: %s", closeErr) } wg.Wait() } </ins> func TestIdleNoTimeoutSet(t *testing.T) { var wg sync.WaitGroup server, listen, serverErr := runServer(&wg)

Discussion:
Hit this while :
cc/ Andy can you take a look at this failure?
looking now
Working with on a fix
Proposed fix:
Change:
gvk := unstructured.GetObjectKind().GroupVersionKind() t := c.parser.Type(gvk) if t == nil { <del> return nil, fmt.Errorf("no corresponding type for %v", gvk) </del> <ins> return nil, newNoCorrespondingTypeError(gvk) </ins> } return t.FromYAML(typed.YAMLObject(string(from))) }

Discussion:
Found by failing TestApplyConvertsManagedFieldsVersion test in () It seems that conversion depends on schema info that is collected from served API versions only. However, managedFields stores data in etcd from REST versions served in previous releases which may no longer be served. That means that we have to be able to deal with managedFields persisted via API calls to versions that are no longer served, but which we still have and understand conversions for. /cc /sig api-machinery /wg apply /priority important-soon
This may be fixed in a more recent version of structured-merge-diff. I'll look into it
/assign
At one point we were using the types registered to the scheme to generate the openAPI definitions used by apply, but we switched to using the installed endpoints instead, because it was less invasive (We needed to expose which types are convertible to which other types, and also a way to skip generating openAPI for internal types). We might want to revisit the first approach, given this use case.
Change:
diskName, diskURI, requestGB, err := b.CreateVolume("testBlob", "testsa", "type", b.common.location, 10) expectedErr := fmt.Errorf("could not get storage key for storage account testsa: could not get storage key for "+ "storage account testsa: Retriable: false, RetryAfter: 0s, HTTPStatusCode: 500, RawError: %w", error(nil)) <del> assert.Equal(t, expectedErr, err) </del> <ins> assert.EqualError(t, err, expectedErr.Error()) </ins> assert.Empty(t, diskName) assert.Empty(t, diskURI) assert.Zero(t, requestGB)

Discussion:
Our internal CI job that runs k8s unit tests with master golang. TestCreateVolume TestDeleteVolume Probably after the master golang GITCOMMIT= Change: https://go- No response 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
^^
Updates: Observed that with the latest version of Go dev branch, the underlying type is no longer fmt.WrapError, but is rather errors.ErrorString when a nil error is using the verb is used. Both, the expected error and the returned error had a similar type until go 1.19 - , which now switched to when a error is wrapped with the verb. The changes are made in where the earlier used is now replaced with to check for error equality. The changes have been tested with both go 1.19 and go 1.20-devel and works as intended.
Change:
}, }, { <ins> name: "handles watch delete multiple", infos: []*resource.Info{ { Mapping: &meta.RESTMapping{ Resource: schema.GroupVersionResource{Group: "group", Version: "version", Resource: "theresource-1"}, }, Name:      "name-foo-1", Namespace: "ns-foo", }, { Mapping: &meta.RESTMapping{ Resource: schema.GroupVersionResource{Group: "group", Version: "version", Resource: "theresource-2"}, }, Name:      "name-foo-2", Namespace: "ns-foo", }, }, fakeClient: func() *dynamicfakeclient.FakeDynamicClient { fakeClient := dynamicfakeclient.NewSimpleDynamicClient(scheme) fakeClient.PrependReactor("get", "theresource-1", func(action clienttesting.Action) (handled bool, ret runtime.Object, err error) { return true, newUnstructured("group/version", "TheKind", "ns-foo", "name-foo-1"), nil }) fakeClient.PrependReactor("get", "theresource-2", func(action clienttesting.Action) (handled bool, ret runtime.Object, err error) { return true, newUnstructured("group/version", "TheKind", "ns-foo", "name-foo-2"), nil }) fakeClient.PrependWatchReactor("theresource-1", func(action clienttesting.Action) (handled bool, ret watch.Interface, err error) { fakeWatch := watch.NewRaceFreeFake() fakeWatch.Action(watch.Deleted, newUnstructured("group/version", "TheKind", "ns-foo", "name-foo-1")) return true, fakeWatch, nil }) fakeClient.PrependWatchReactor("theresource-2", func(action clienttesting.Action) (handled bool, ret watch.Interface, err error) { fakeWatch := watch.NewRaceFreeFake() fakeWatch.Action(watch.Deleted, newUnstructured("group/version", "TheKind", "ns-foo", "name-foo-2")) return true, fakeWatch, nil }) return fakeClient }, timeout: 10 * time.Second, validateActions: func(t *testing.T, actions []clienttesting.Action) { if len(actions) != 2 { t.Fatal(spew.Sdump(actions)) } if !actions[0].Matches("list", "theresource-1") { t.Error(spew.Sdump(actions)) } if !actions[1].Matches("list", "theresource-2") { t.Error(spew.Sdump(actions)) } }, }, { </ins> name: "ignores watch error", infos: []*resource.Info{ {

Discussion:
We should consider updating the command to wait on all resources for a given kind. For example: would wait for every pod in the current namespace to be deleted. /sig cli cc
Interestingly, the error text implies that this is already supported: Yet when you try to use it, it declares Would really like the wait functionality given some much needed TLC. Still no way to determine what conditions are supported for various resources (eg. I can say and it just waits for the timeout like that resource might actually potato at some point).
I'm looking into adding the --all flag to wait, sounds like a nice feature to have :)