jiebi/CodeConvo huggingface dataset:
Change:
// HasStatusCause returns true if the provided error has a details cause // with the provided type name. <ins> // It supports wrapped errors and returns false when the error is nil. </ins> func HasStatusCause(err error, name metav1.CauseType) bool { _, ok := StatusCause(err, name) return ok } // StatusCause returns the named cause from the provided error if it exists and <del> // the error is of the type APIStatus. Otherwise it returns false. </del> <ins> // the error unwraps to the type APIStatus. Otherwise it returns false. </ins> func StatusCause(err error, name metav1.CauseType) (metav1.StatusCause, bool) { <del> apierr, ok := err.(APIStatus) if !ok || apierr == nil || apierr.Status().Details == nil { return metav1.StatusCause{}, false } for _, cause := range apierr.Status().Details.Causes { if cause.Type == name { return cause, true </del> <ins> status, ok := err.(APIStatus) if (ok || errors.As(err, &status)) && status.Status().Details != nil { for _, cause := range status.Status().Details.Causes { if cause.Type == name { return cause, true } </ins> } } return metav1.StatusCause{}, false

Discussion:
I have a controller that creates objects. It uses to notice when create fails due to a deleting namespace. This check was working well until I moved it away from each call. In some cases, the error is wrapped using causing the function to always return false. I expected to work on both wrapped and unwrapped errors, like the functions do. This short program shows the issue: I am able to work around it by first calling . This type assertion should be replaced with a call to : /sig api-machinery v1.22.5, but I also see the affected code in master. <details</detailsn/a n/a k3s n/a n/a
/cc /triage accepted
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Change:
// Periodically refresh the RESTMapper with new discovery information and sync // the garbage collector. <del> go garbageCollector.Sync(gcClientset.Discovery(), 30*time.Second, ctx.Stop) </del> <ins> go garbageCollector.Sync(discoveryClient, 30*time.Second, ctx.Stop) </ins> return garbagecollector.NewDebugHandler(garbageCollector), true, nil }

Discussion:
Ran kube-controller-manager with and observed this in the log every 30 seconds: This is also happening in 1.20, 1.19, and 1.18 The GC and quota clients look up discovery information every 30 seconds. They have a QPS of 20 requests per second and a burst of 30 requests. Default configuration of kube-controller-manager runs without constant throttling warnings. /sig api-machinery
/assign /triage accepted
Change:
// restart may think these old pods are consuming CPU and we // will get an OutOfCpu error. ginkgo.By("verifying restartNever pods succeed and restartAlways pods stay running") <del> for start := time.Now(); time.Since(start) < startTimeout; time.Sleep(10 * time.Second) { postRestartRunningPods := waitForPods(f, numAllPods, time.Minute) if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) } </del> <ins> postRestartRunningPods := waitForPods(f, numAllPods, startTimeout) if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) </ins> } }) })

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:
// Storing endpoint of newly registered DRA Plugin into the map, where plugin name will be the key // all other DRA components will be able to get the actual socket of DRA plugins by its name. draPlugins.Set(pluginName, &Plugin{ <ins> conn:                    nil, </ins> endpoint:                endpoint, highestSupportedVersion: highestSupportedVersion, })

Discussion:
See comment for details:
/sig node
/area kubelet
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted
Change:
case core.ResourceQuotaScopeBestEffort, core.ResourceQuotaScopeNotBestEffort, core.ResourceQuotaScopeTerminating, core.ResourceQuotaScopeNotTerminating, core.ResourceQuotaScopeCrossNamespacePodAffinity: if req.Operator != core.ScopeSelectorOpExists { allErrs = append(allErrs, field.Invalid(fldPath.Child("operator"), req.Operator, <del> "must be 'Exist' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity")) </del> <ins> "must be 'Exists' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity")) </ins> } }

Discussion:
On the document, the operator should be 'Exists' ! But in the Error message, it becomes 'Exist' ! the error message should be create a yaml and apply it It's my first time, I am not sure should we change to ? <details</details<detailsK3S </details<details</details<details</details<details</details<details</details
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 apps
/assign
/assign
Change:
#TODO(mikedanese): allow static pods to start before creating a client #flags+=" --bootstrap-kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig" #flags+=" --kubeconfig=/var/lib/kubelet/kubeconfig" <ins> flags+=" --register-with-taints=node-role.kubernetes.io/master=:NoSchedule" </ins> flags+=" --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig" flags+=" --register-schedulable=false" fi

Discussion:
What happened: Created a daemonset ala but missing the master toleration. The created pods are running on every node, including the master. What you expected to happen: Lacking the master toleration, I would expect there to be no pod from the daemonset running on the master. Realized the master Node is missing the master taint. How to reproduce it (as minimally and precisely as possible): Created a daemonset on GCE with no tolerations. (You may need to set the priorityClassName: system-cluster-critical) Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: GCE 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 a sig label 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. <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
Change:
// InstanceShutdownByProviderID returns true if the instance is in safe state to detach volumes func (az *Cloud) InstanceShutdownByProviderID(ctx context.Context, providerID string) (bool, error) { <del> return false, cloudprovider.NotImplemented </del> <ins> nodeName, err := az.vmSet.GetNodeNameByProviderID(providerID) if err != nil { return false, err } provisioningState, err := az.vmSet.GetProvisioningStateByNodeName(string(nodeName)) if err != nil { return false, err } return strings.ToLower(provisioningState) == "stopped" || strings.ToLower(provisioningState) == "deallocated", nil </ins> } // getComputeMetadata gets compute information from instance metadata.

Discussion:
Implement proposal for Azure We should implement interface in Azure cloud provider. returns true if the instance is in stopped state to detach volumes. But if instance is deleted we should not return error. Related features: Related proposal: Related PRs: /kind feature /sig azure /cc
- can you assign me on this one ? I already have a PR in flight.
That's great! /assign just loop in for this RP review, thanks.
GitHub didn't allow me to assign the following users: yastij. Note that only and repo collaborators can be assigned. <detailsIn response to : That's great! /assign just loop in for this RP review, thanks. 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
o, you are not a k8s member yet, anyway, you could send out the PR for this feature, related to this issue, thanks.
Thanks, looking forward to your PR.
Change:
} ctx, cancel := watchtools.ContextWithOptionalTimeout(context.Background(), timeout) defer cancel() <del> _, err := watchtools.UntilWithSync(ctx, lw, &v1.ServiceAccount{}, nil, serviceAccountHasSecrets) </del> <ins> _, err := watchtools.UntilWithSync(ctx, lw, &v1.ServiceAccount{}, nil, func(event watch.Event) (bool, error) { switch event.Type { case watch.Deleted: return false, apierrors.NewNotFound(schema.GroupResource{Resource: "serviceaccounts"}, serviceAccountName) case watch.Added, watch.Modified: return true, nil } return false, nil }) </ins> return err } <del> // serviceAccountHasSecrets returns true if the service account has at least one secret, // false if it does not, or an error. func serviceAccountHasSecrets(event watch.Event) (bool, error) { switch event.Type { case watch.Deleted: return false, apierrors.NewNotFound(schema.GroupResource{Resource: "serviceaccounts"}, "") } switch t := event.Object.(type) { case *v1.ServiceAccount: return len(t.Secrets) > 0, nil } return false, nil } </del> // WaitForDefaultServiceAccountInNamespace waits for the default service account to be provisioned // the default service account is what is associated with pods when they do not specify a service account // as a result, pods are not able to be provisioned in a namespace until the service account is provisioned

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:
var output string output, err = remote.SSH(name, "sh", "-c", <del> "'systemctl list-units  --type=service  --state=running | grep -e docker -e containerd'") </del> <ins> "'systemctl list-units  --type=service  --state=running | grep -e docker -e containerd -e crio'") </ins> if err != nil { <del> err = fmt.Errorf("instance %s not running docker/containerd daemon - Command failed: %s", name, output) </del> <ins> err = fmt.Errorf("instance %s not running docker/containerd/crio daemon - Command failed: %s", name, output) </ins> continue } if !strings.Contains(output, "docker.service") && <del> !strings.Contains(output, "containerd.service") { err = fmt.Errorf("instance %s not running docker/containerd daemon: %s", name, output) </del> <ins> !strings.Contains(output, "containerd.service") && !strings.Contains(output, "crio.service") { err = fmt.Errorf("instance %s not running docker/containerd/crio daemon: %s", name, output) </ins> continue } instanceRunning = true

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: /test pull-kubernetes-node-crio1-18-e2e Which test(s) are failing: pull-kubernetes-node-crio1-18-e2e Reason for failure: Just before node e2e tests are started, we verify that the runtime (containerd or docker) is properly running or not on the target system. This check doesn't include crio, so the targeted node is not reported ready if it's using crio as the runtime.
/sig testing
/sig node /remove-sig testing This check is owned by SIG node
The code has also not allowed this sort of dependency (beyond some legacy dockershim specific bits), but I guess it's somewhat more understandable to check in .
Change:
} strOut := strings.TrimSuffix(string(out), "n") <del> glog.V(5).Infof("IsLikelyNotMountPoint findmnt output: %v", strOut) </del> <ins> glog.V(5).Infof("IsLikelyNotMountPoint findmnt output for path %s: %v", file, strOut) </ins> if strOut == file { return false, nil }

Discussion:
Currently, there many error messages in that do not contain any context. This means that these messages are basically meaningless in real systems where many pods may be on a node. Examples: Every error message in this file should identify the path that the message is in relation to.
Can you handle this, since you most recently touched in ?
Change:
fakeCloud            *fake_cloud.FakeCloud matchRE              string expectedRequestCount int <del> expectedCreated      []string </del> <ins> expectedNameCreated  []string expectedExtIDCreated []string </ins> expectedDeleted      []string }{ {

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).
Change:
set_num_migs if [[ ${KUBE_USE_EXISTING_MASTER:-} == "true" ]]; then <ins> parse-master-env </ins> create-nodes create-autoscaler else

Discussion:
When we add nodes to an existing cluster, we need to reuse the existing configuration. In particular, we need to extract the kubelet cert & key, otherwise we get a cert error connecting to the master.
WIP fix in
Change:
import ( "bytes" <del> "context" </del> "encoding/json" "fmt" "io/ioutil"

Discussion:
The upper test heavily flakes in master:
/cc
Hey I think this might have something to do with your changes. Something is definitely a bit off. It probably is a faulty test...
duplicate of
Looks like an occasional failure, and I don't think this is caused by my code change because I run tests for a few times, and sometime it is passed.... Still I can help to locate the root cause.
I revert my code change, test still fails from time to time...
I think i've found out the root cause, I'll pull a request soon, . cc

Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: //pkg/kubelet/dockershim/network/cni:godefaulttest Since when has it been failing: Unsure, it doesn't appear in triage, but I see it regularly in PRs. Testgrid link: This package is the top flake currently Reason for failure: Anything else we need to know: /sig node /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
The test results have the following three phenomena. b c
Change:
RestartPolicy: v1.RestartPolicyNever, Containers: []v1.Container{ { <del> Name:  fmt.Sprintf("%s-container", podName), </del> <ins> Name:  "client", </ins> Image: imageutils.GetE2EImage(imageutils.BusyBox), Args: []string{ "/bin/sh",

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: In tests, always fails when the tests fail, with the error: . This is the message indicating that APIServer responds 400 code. What you expected to happen: Container logs should be collected correctly if tests fail. How to reproduce it (as minimally and precisely as possible): a NetworkPolicy test to make it fail and run it, or run NetworkPolicy tests with a CNI that doesn't implement NetworkPolicy. the tests fail, all attempts to get container logs will fail like the following. Anything else we need to know?: Environment: Kubernetes version (use ): 16.3 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 /assign
/remove-sig testing /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
return fmt.Sprintf("%s:%d/%s", s.IP, s.Port, s.Protocol) } <ins> type realServerKey struct { Address net.IP Port    uint16 } func (r *realServerKey) String() string { return net.JoinHostPort(r.Address.String(), strconv.Itoa(int(r.Port))) } </ins> //NewFake creates a fake ipvs implementation - a cache store. func NewFake() *FakeIPVS { return &FakeIPVS{

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: IPVS real server can't be right deleted in FakeIPVS for ipvs testing. What you expected to happen: When delete ipvs real server, we can't give the weight information, so we can't use deep equal in .
/sig network /area ipvs
/kind bug