jiebi/CodeConvo huggingface dataset:
Change:
<ins> /* Copyright 2020 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 fake import ( "bytes" "context" "io" "testing" corev1 "k8s.io/api/core/v1" cgtesting "k8s.io/client-go/testing" ) func TestFakePodsGetLogs(t *testing.T) { fp := FakePods{ Fake: &FakeCoreV1{Fake: &cgtesting.Fake{}}, ns:   "default", } req := fp.GetLogs("foo", &corev1.PodLogOptions{}) body, err := req.Stream(context.Background()) if err != nil { t.Fatal("Stream pod logs:", err) } var buf bytes.Buffer n, err := io.Copy(&buf, body) if err != nil { t.Fatal("Read pod logs:", err) } if n == 0 { t.Fatal("Empty log") } err = body.Close() if err != nil { t.Fatal("Close response body:", err) } } </ins>

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: I tried to use  in a unit test, however I get a nil pointer panic when is invoked. What you expected to happen: would return a that doesn't panic on any method call. Ideally, it would allow me to interact with the client in someway for testing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: client-go version: 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 testing
I believe this also impacts returning logs via a reactor as does not implement
Seems to be a problem with . Since we're creating the request with all empty fields. Not sure what the best way it to resolve this. The best thing I came up with is to use to return a request with everything set up. But I'm a noob here so that's just a shot in the dark :man_shrugging:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
The request returned has a nil which is used in the
I have filed a PR trying to fix this issue.
Change:
// namespaces if it's namespace scoped, so leave // APIResource.Namespaced as false is all right. apiResource := unversioned.APIResource{Name: resource.Resource} <del> // The default parameter codec used by the dynamic client cannot // encode api.ListOptions. // TODO: api.ParameterCodec doesn't support thirdparty objects. // We need a generic parameter codec. return client.ParameterCodec(api.ParameterCodec).Resource(&apiResource, api.NamespaceAll).List(&options) </del> <ins> return client.ParameterCodec(dynamic.VersionedParameterEncoderWithV1Fallback). Resource(&apiResource, api.NamespaceAll). List(&options) </ins> }, WatchFunc: func(options api.ListOptions) (watch.Interface, error) { // APIResource.Kind is not used by the dynamic client, so

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
library = ":go_default_library", deps = [ "//vendor/k8s.io/api/admissionregistration/v1alpha1:go_default_library", <ins> "//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", <ins> "//vendor/k8s.io/apiserver/pkg/admission:go_default_library", "//vendor/k8s.io/apiserver/pkg/authorization/authorizer:go_default_library", </ins> ], )

Discussion:
There are two issues: doesn't have merge key The validation code regards it as an error if both Initializers.Result and Initializers.Pending are nil. So if multiple initializer controllers sending patches removing themselves from Initializers.Pending at the same time, the last patch that gets applied will get a validation error.
/sig api-machinery
Change:
NetworkPluginName:         s.NetworkPluginName, NetworkPlugins:            ProbeNetworkPlugins(s.NetworkPluginDir), NodeStatusUpdateFrequency: s.NodeStatusUpdateFrequency, <ins> OOMAdjuster:               oom.NewOOMAdjuster(), </ins> OSInterface:               kubecontainer.RealOS{}, PodCIDR:                   s.PodCIDR, PodInfraContainerImage:    s.PodInfraContainerImage,

Discussion:
The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign See PR for docs at 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
~This would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.
Change:
return valueFrom } <ins> func describeStatus(stateName string, state api.ContainerState, out io.Writer) { switch { case state.Running != nil: fmt.Fprintf(out, "    %s:tRunningn", stateName) fmt.Fprintf(out, "      Started:t%vn", state.Running.StartedAt.Time.Format(time.RFC1123Z)) case state.Waiting != nil: fmt.Fprintf(out, "    %s:tWaitingn", stateName) if state.Waiting.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Waiting.Reason) } case state.Terminated != nil: fmt.Fprintf(out, "    %s:tTerminatedn", stateName) if state.Terminated.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Terminated.Reason) } if state.Terminated.Message != "" { fmt.Fprintf(out, "      Message:t%sn", state.Terminated.Message) } fmt.Fprintf(out, "      Exit Code:t%dn", state.Terminated.ExitCode) if state.Terminated.Signal > 0 { fmt.Fprintf(out, "      Signal:t%dn", state.Terminated.Signal) } fmt.Fprintf(out, "      Started:t%sn", state.Terminated.StartedAt.Time.Format(time.RFC1123Z)) fmt.Fprintf(out, "      Finished:t%sn", state.Terminated.FinishedAt.Time.Format(time.RFC1123Z)) default: fmt.Fprintf(out, "    %s:tWaitingn", stateName) } } </ins> func printBool(value bool) string { if value { return "True"

Discussion:
Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .
Change:
return errors.NewBadRequest(msg) } <del> for i, existingObj := range t.objects[gvr] { oldMeta, err := meta.Accessor(existingObj) if err != nil { return err } if oldMeta.GetNamespace() == newMeta.GetNamespace() && oldMeta.GetName() == newMeta.GetName() { if replaceExisting { for _, w := range t.getWatches(gvr, ns) { w.Modify(obj) } t.objects[gvr][i] = obj return nil </del> <ins> _, ok := t.objects[gvr] if !ok { t.objects[gvr] = make(map[types.NamespacedName]runtime.Object) } namespacedName := types.NamespacedName{Namespace: newMeta.GetNamespace(), Name: newMeta.GetName()} if _, ok = t.objects[gvr][namespacedName]; ok { if replaceExisting { for _, w := range t.getWatches(gvr, ns) { w.Modify(obj) </ins> } <del> return errors.NewAlreadyExists(gr, newMeta.GetName()) </del> <ins> t.objects[gvr][namespacedName] = obj return nil </ins> } <ins> return errors.NewAlreadyExists(gr, newMeta.GetName()) </ins> } if replaceExisting {

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: I used to fake a clientset to test my code. I found that it became very slow to init the clientset with a big number of objects when I was trying to simulate a large scale cluster, and the time seemed exponential increasing. For example: Initializing a clientset with: 5000 objects took 300ms objects took 2.58s objects took 11.82s objects took 54.64s. It's because the fake clientset used a slice to store each kind of objects, so it's quite slow to init the clientset with massive objects because it checked existence of an object by traversing all objects and comparing with them before adding one, which leads to O(n^2) time complexity. What you expected to happen: The fake clientset is very useful for development, it should have a reasonable time complexity to allow developers to use it for large scale scenario. How to reproduce it (as minimally and precisely as possible): Run this code: You would see the time spent on each operation, like: Anything else we need to know?: Environment: Kubernetes version (use ): 1.15.0-1.18.0 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:
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
I had PR that uses map to store objects, which can reduce the init time to a reasonable value (tens of ms for objects). /assign
Change:
cat >> "${config_path}" <<EOF # Setup a runtime with the magic name ("test-handler") used for Kubernetes # runtime class tests ... <del> [plugins.cri.containerd.runtimes.test-handler] runtime_type = "io.containerd.runtime.v1.linux" </del> <ins> [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.test-handler] runtime_type = "io.containerd.runc.v2" </ins> EOF fi

Discussion:
Both jobs are failing with the same error message. pull-kubernetes-e2e-gce-ubuntu-containerd gce-ubuntu-master-containerd Tests are not run as clusters fail to come up. gce-ubuntu-master-containerd: Cluster creations failures started 2021/04/09 05:09 AM PST. pull-kubernetes-e2e-gce-ubuntu-containerd: Cluster creation failures started around 2021/04/08 3:15 AM PST Cluster creation script fails
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
I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/etcd-server-e2e---master" I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/kube-apiserver-e2e---master" I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/kube-controller-manager-e2e---master" E0410 20:45:23. ] "Version from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" E0410 20:45:23. ] "Get runtime version failed" err="get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" E0410 20:45:23. ] "Failed to run kubelet" err="failed to run Kubelet: failed to create kubelet: get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" kubelet.service: Main process exited, code=exited, status=1/FAILURE kubelet.service: Failed with result 'exit-code'.
Looks like infra-commit is related PR: /cc
fix is going in here
Change:
skew := matchNum + selfMatchNum - minMatchNum if skew > c.maxSkew { klog.V(5).Infof("node '%s' failed spreadConstraint[%s]: matchNum(%d) + selfMatchNum(%d) - minMatchNum(%d) > maxSkew(%d)", node.Name, tpKey, matchNum, selfMatchNum, minMatchNum, c.maxSkew) <del> return migration.PredicateResultToFrameworkStatus([]predicates.PredicateFailureReason{predicates.ErrTopologySpreadConstraintsNotMatch}, nil) </del> <ins> return framework.NewStatus(framework.Unschedulable, ErrReasonConstraintsNotMatch) </ins> } }

Discussion:
Part of /priority important-soon See example /sig scheduling /kind cleanup
/help
/assign
/remove-help
Change:
oomTargetContainerName string } <del> var _ = SIGDescribe("OOMKiller [LinuxOnly] [NodeConformance]", func() { </del> <ins> // Marked as [Serial] since currently the runtime can miss the OOM event if the pod is killed too quickly. This seems // to occur more often when the node is highly loaded. var _ = SIGDescribe("OOMKiller [LinuxOnly] [NodeConformance] [Serial]", func() { </ins> f := framework.NewDefaultFramework("oomkiller-test") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged

Discussion:
E2eNode Suite.[It] [sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api E2eNode Suite.[It] [sig-node] OOMKiller [LinuxOnly] [NodeConformance] single process container The containers terminated by OOM killer should have the reason set to OOMKilled 7/22 No response No response /sig node
The problem with OOM kill looks the same as this pr
will fix this and is already approved(wait for 1.28 release and merge then). /assign
/triage accepted
That PR has been merged, but the problem continues to occur, for example today in
Still seeing this occur fairly regularly. I tested locally just increasing the length of the sleep call, but depending on the node load it still flaked. I'm hopeful but not certain that marking the test as serial in will eliminate the flake.
/reopen
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 created to revert the change to serial. It doesn't completely resolve the issue, will be digging into this deeper when I get some time.
This looks like a containerd issue and already created a ticket there. I looked at containerd logs from a good and bad test run. In the good run, we get a in the container stopped event. In the bad run, we get a on the container stopped event.
Linking containerd tickets for completeness:
do you think it is a quick start in our case? Or something else
I don't think so since the sleep didn't appear to help. containerd reads the file in the cgroup directory to discover OOM kills. I think what's happening is some race where the cgroup directory gets cleaned up before it has a chance to read the file. I did some testing and when it fails, containerd tries to read but it has already been removed.
/retitle OOMKiller tests are flaking - sometimes condition returned as Failed instead of OOMKilled
/priority important-soon I suppose that we should fix it or at least make it less flaking.
I started to do this the other day.

I didn't see any good way other than by listing processes and looking for containerd, skipping the test in that case. Seemed like a giant hack, but WDYT?
According to , we may skip it due to and
Not flake in recent three weeks. /close
Closing this issue. <detailsIn response to : Not flake in recent three weeks. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
eventCorrelator := NewEventCorrelator(util.RealClock{}) return eventBroadcaster.StartEventWatcher( func(event *api.Event) { <del> // Make a copy before modification, because there could be multiple listeners. // Events are safe to copy like this. eventCopy := *event event = &eventCopy result, err := eventCorrelator.EventCorrelate(event) if err != nil { util.HandleError(err) } if result.Skip { return } tries := 0 for { if recordEvent(sink, result.Event, result.Patch, result.Event.Count > 1, eventCorrelator) { break } tries++ if tries >= maxTriesPerEvent { glog.Errorf("Unable to write event '%#v' (retry limit exceeded!)", event) break } // Randomize the first sleep so that various clients won't all be // synced up if the master goes down. if tries == 1 { time.Sleep(time.Duration(float64(sleepDuration) * randGen.Float64())) } else { time.Sleep(sleepDuration) } } </del> <ins> recordToSink(sink, event, eventCorrelator, randGen) </ins> }) } <ins> func recordToSink(sink EventSink, event *api.Event, eventCorrelator *EventCorrelator, randGen *rand.Rand) { // Make a copy before modification, because there could be multiple listeners. // Events are safe to copy like this. eventCopy := *event event = &eventCopy result, err := eventCorrelator.EventCorrelate(event) if err != nil { util.HandleError(err) } if result.Skip { return } tries := 0 for { if recordEvent(sink, result.Event, result.Patch, result.Event.Count > 1, eventCorrelator) { break } tries++ if tries >= maxTriesPerEvent { glog.Errorf("Unable to write event '%#v' (retry limit exceeded!)", event) break } // Randomize the first sleep so that various clients won't all be // synced up if the master goes down. if tries == 1 { time.Sleep(time.Duration(float64(sleepDuration) * randGen.Float64())) } else { time.Sleep(sleepDuration) } } } </ins> func isKeyNotFoundError(err error) bool { statusErr, _ := err.(*errors.StatusError) // At the moment the server is returning 500 instead of a more specific

Discussion:
Have not reproduced locally even after a few tens of runs.
which version of Go are you using locally? This probably only repros on 1.5.1.
This was from Jenkins runs.
This is caused because an attempts counter is being read/written to without synchronization. I think this is caused by the event creation order not being guaranteed. I am looking a little deeper to track this down.
Got a fix with 130k+ runs and no failures. Will send out PR shortly.
Change:
echo "For address ${full_address}, got ${status} but wanted ${desired}" return 1 } <ins> # TODO: Remove this function when we do the retry inside the kubectl commands. See #15333. function kubectl-with-retry() { ERROR_FILE="${KUBE_TEMP}/kubectl-error" for count in $(seq 0 3); do kubectl "$@" 2> ${ERROR_FILE} || true if grep -q "the object has been modified" "${ERROR_FILE}"; then kube::log::status "retry $1, error: $(cat ${ERROR_FILE})" rm "${ERROR_FILE}" sleep $((2**count)) else rm "${ERROR_FILE}" break fi done } </ins> kube::util::trap_add cleanup EXIT SIGINT kube::util::ensure-temp-dir

Discussion:
shippable flake: It seems that this test needs to retry on update failures. cc who fixed some other similar test flakes recently and might want to take a swing at this one.
cc
We discussed about it in Assigning to
Thanks . Removing team/control-plane, as team/CSI seem to have this in hand.
Aha, my PR was also hit by this flake just now. I'll try to fix this tmr.
has the same problem.
Change:
return false, nil } <ins> func (n *NsenterMounter) absHostPath(command string) string { path, ok := n.paths[command] if !ok { return command } return path } </ins>

Discussion:
What happened: Windows documentation claims: V1.VolumeMount.mountPropagation - only MountPropagationHostToContainer is available. However, the internals suggest otherwise; is always returned on Windows: Either the docs should be corrected, or the Kubelet should be updated, or we should have a comment on why this does in fact enable MountPropagationHostToContainer on Windows. /cc /sig windows
/cc
/cc
I think the doc is not accurate. The doc claims the same thing. For MountPropagationHostToContainer option, we can test it whether it is working or not.
i created two PRs to address the documentation gap. we will also test this and get back to this thread.
For 1.15 we may need to update Kubelet code to allow HostToContainer.
Change:
"expansion.go", "host_path.go", "init_container.go", <ins> "kubelet.go", </ins> "kubelet_etc_hosts.go", "lifecycle_hook.go", "networking.go",

Discussion:
What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. To my eyes they may meet the criteria for conformance. There's definitely nothing about them that is node specific. They should be running as part of our regular CI, and they should probably be running as presubmits. Porting them to test/e2e/common would cause this to happen. /kind cleanup /sig node /area test /assign
GitHub didn't allow me to assign the following users: mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. /sig node /area test /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