jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestRunArgsFollowDashRules(t *testing.T) { _, _, rc := testData() tests := []struct { args          []string argsLenAtDash int expectError   bool name          string }{ { args:          []string{}, argsLenAtDash: -1, expectError:   true, name:          "empty", }, { args:          []string{"foo"}, argsLenAtDash: -1, expectError:   false, name:          "no cmd", }, { args:          []string{"foo", "sleep"}, argsLenAtDash: -1, expectError:   false, name:          "cmd no dash", }, { args:          []string{"foo", "sleep"}, argsLenAtDash: 1, expectError:   false, name:          "cmd has dash", }, { args:          []string{"foo", "sleep"}, argsLenAtDash: 0, expectError:   true, name:          "no name", }, } for _, test := range tests { f, tf, codec := NewAPIFactory() tf.Client = &fake.RESTClient{ Codec: codec, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { return &http.Response{StatusCode: 201, Body: objBody(codec, &rc.Items[0])}, nil }), } tf.Namespace = "test" tf.ClientConfig = &client.Config{} cmd := NewCmdRun(f, os.Stdin, os.Stdout, os.Stderr) cmd.Flags().Set("image", "nginx") err := Run(f, os.Stdin, os.Stdout, os.Stderr, cmd, test.args, test.argsLenAtDash) if test.expectError && err == nil { t.Errorf("unexpected non-error (%s)", test.name) } if !test.expectError && err != nil { t.Errorf("unexpected error: %v (%s)", err, test.name) } } } </ins> func TestGenerateService(t *testing.T) { tests := []struct {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-enabled-default Which test(s) are failing: CSI hostpath-v0 tests Since when has it been failing: 8/8 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: We are removing CSI 0.3 support in 1.18, which is before selflink is going to be removed in 1.20. So we should just disable hostpath-v0 from alpha tests. /assign
/milestone v1.16
Change:
// Partially update a node using strategic merge patch kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' <ins> // Update a container's image; spec.containers[*].name is required because it's a merge key kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' </ins> ``` ### Options

Discussion:
The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.
Change:
} }` <ins> crdApplyFinalizerBody = ` { "apiVersion": "%s", "kind": "%s", "metadata": { "name": "%s", "finalizers": %s }, "spec": { "knownField1": "val1", "ports": [{ "name": "portName", "containerPort": 8080, "protocol": "TCP", "hostPort": 8082 }], "embeddedObj": { "apiVersion": "v1", "kind": "ConfigMap", "metadata": { "name": "my-cm", "namespace": "my-ns" } } } }` </ins> patchYAMLBody = ` apiVersion: %s kind: %s metadata: name: %s finalizers: <del> - test-finalizer </del> <ins> - test/finalizer </ins> spec: cronSpec: "* * * * */5" ports:

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
Type:    "DisruptionTarget", Status:  "True", Reason:  "TerminationByKubelet", <del> Message: "The node was low on resource: ephemeral-storage. ", </del> <ins> Message: "The node was low on resource: ephemeral-storage. Threshold quantity: 2Gi, available: 1536Mi. ", </ins> }) }

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
StorageConfig:           endpointConfig, Decorator:               generic.UndecoratedStorage, DeleteCollectionWorkers: 0, <del> ResourcePrefix:          c.ExtraConfig.StorageFactory.ResourcePrefix(kapi.Resource(DefaultStorageEndpoint)), </del> <ins> ResourcePrefix:          c.ExtraConfig.StorageFactory.ResourcePrefix(kapi.Resource("endpoints")), </ins> }) endpointRegistry := endpoint.NewRegistry(endpointsStorage) masterLeases := reconcilers.NewLeases(leaseStorage, "/masterleases/", ttl)

Discussion:
/kind bug The lease reconciler creates the kubernetes endpoint with a prefix of kube-apiserver-endpoint, however that is not the prefix that the rest of kube uses. The end result is that the kubernetes service doesn't have an endpoint, and kubectl won't list the kubernetes endpoint. The lease reconciler also creates lease files with a really long lease time instead of the default 15 seconds.
/cc
cc xref
kube-apiserver-endpoint is used for the lease itself, from what I remember. I don't think that's an issue by itself.
Oh but it does look like the endpointRegistry for the lease reconciler is misconfigured to use that
i'll look into it
what is the name that should be used?
services/endpoints afaik -
Yeah, making that change locally fixed it for me
But I'm not seeing the masterleases/apiServerIPInfo data in etcd, or I'm issuing the wrong command to find it
I had that same problem. The lease timeout is set way high, but for some reason that resulted in the lease files being created for only a very short time. I'm not sure why. Playing with the ttl amount got the lease files to stay around....forever. I've got a PR I'm about to push to fix both issues.
FYI has a PR for this now
cc
Change:
# This script will build a dev release and bring up a new cluster with that # release. <ins> set -e </ins> # First build the binaries $(dirname $0)/build-go.sh if [ "$?" != "0" ]; then

Discussion:
As I discovered the hard way, if the json GCS api is not turned on for a project, will not surface this error, but just loop 'forever'. API access errors should be easy to catch, so it would be great to surface them on cluster startup and abort with a useful message. (I might take a look at this).
This is described in step 3 of But I agree that it would be better if the tool could catch this case and let the user know (it bit me the first time I tried to run that script as well).
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util/wait" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Discussion:
Still early in diagnosis, but soon after cutting 0.17.0, our early internal testing show this test as flaking. It's pretty bizarre, though, given the test isn't flaking on GCE, or even the continuous integration runs on GKE.
cc
So far, I've tried reproing this on a bare cluster 100 times, no joy. Now I'm trying up/test/down, no immediate joy (but it's a flake). If I get to the point of testing up/e2e/down, I might as well call it "Jenkins" and be done with it, but I guess it's time to start looking through logs instead. (As for the P0, trying to figure out if we need a cherry-pick, or if we let the flake proceed on in the entire 0.17.0 train.)
+1 to ironing out a flake; v0.16.0 had a flake (or maybe even a consistently-failing test) which made us turn off tests that would run against it for weeks. This is especially important now that we're doing soak tests.
(since it's related to events)
The test itself looks racy; there's nothing to guarantee that the events will have made it through the system by the time the pod is running. Generally one would expect that, but there's no guarantee.
Can you paste some sample failures here?
go/k8s-test/job/kubernetes-e2e-gke-test/4534/console
Actually this test is flaky across the board, and has been for some time. If you look at kubernetes-e2e-gce Test Results Analyser in Jenkins, you'll see about 8 failures in the past few hundred runs. I think lavalamp is correct - the test needs to retry/wait for the events to get through. Specifically, this code needs to be wrapped in a util.Poll():
Yeah if the kubelet event shows up less often than the scheduler event, that would make sense, since there'll have been less time.
I can whip up a quick fix now.
If it's a known flake, it's not going to block us. We should get a fix in soon for the next release, though.
Nearly done.
Change:
else # no file exists. Adding a new file <del> cat <<EOF > "$juDIR/junit-$suite.xml" </del> <ins> cat <<EOF > "$juDIR/junit_$suite.xml" </ins> <?xml version="1.0" encoding="UTF-8"?> <testsuites> <testsuite failures="$errors" assertions="$assertions" name="$suite" tests="1" errors="$errors" time="$total">

Discussion:
is not picking the cmd test junit output due to file naming issue. The file name should match regex /assign
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig testing
Change:
if new, ok := newContainerIndex[old.Name]; !ok { allErrs = append(allErrs, field.Forbidden(specPath, fmt.Sprintf("existing ephemeral containers %q may not be removedn", old.Name))) } else if !apiequality.Semantic.DeepEqual(old, *new) { <del> specDiff := diff.ObjectDiff(old, *new) </del> <ins> specDiff := cmp.Diff(old, *new) </ins> allErrs = append(allErrs, field.Forbidden(specPath, fmt.Sprintf("existing ephemeral containers %q may not be changedn%v", old.Name, specDiff))) } }

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 --pod with nodeSeletor edit pod, delete the nodeSeletor field report error with: ! The errors message should displayed as: Because the nodeSeletor is been deleted with this edit. 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:
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 api
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api 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
/sig api-machinery
/remove-sig api-machinery /sig apps
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 stale
/remove-lifecycle rotten
Change:
// Update server with new CRD condition. _, err = ec.crdClient.CustomResourceDefinitions().UpdateStatus(crd) <ins> if apierrors.IsNotFound(err) || apierrors.IsConflict(err) { // deleted or changed in the meantime, we'll get called again return nil } </ins> if err != nil { return err }

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
} // Pass all parameters as volume labels for Portworx server-side processing <del> if len(p.options.Parameters) > 0 { spec.VolumeLabels = p.options.Parameters } else { </del> <ins> if spec.VolumeLabels == nil { </ins> spec.VolumeLabels = make(map[string]string, 0) } <ins> for k, v := range p.options.Parameters { spec.VolumeLabels[k] = v } </ins> // Update the requested size in the spec spec.Size = uint64(requestGiB * volumehelpers.GiB)

Discussion:
What happened: The Portworx volume driver is accessing the storage parameters and also modifying it. This is a shared map object used by all PVCs being created at that time from the same StorageClass. This causes 2 issues: Portworx driver ends up saving annotations of one PVC into the parameters of another PVC as both CreateVolume calls use the same map. See controller manager crashes as 2 CreateVolume routines try to modify the same map. This is a big problem since the controller manager container crashes half way into creating a volume resulting in the volume being present in the backend portworx cluster but not bound in Kubernetes. What you expected to happen: CreateVolume call for one PVC should be completely isolated from another PVC How to reproduce it (as minimally and precisely as possible): Create a large number of PVCs using the Portworx volume driver using the same StorageClass. Anything else we need to know?: Environment: n/a Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: Kubernetes cluster with Portworx installed Others:
/sig storage
I'll take care of fixing this
Change:
// Addf logs info immediately. func (passthroughLogger) Addf(format string, data ...interface{}) { <del> glog.Infof(format, data...) </del> <ins> glog.InfoDepth(1, fmt.Sprintf(format, data...)) </ins> } // DefaultStacktracePred is the default implementation of StacktracePred.

Discussion:
the file and line for these log statements is in the That's not helpful I1031 11:09:06. ] 'foo' has no storage object I1031 11:09:06. ] 'pods' is not a redirector I'd rather see Maybe use runtime.Caller in httplog to somehow fake the log to come from the caller's file/line.
Yeah-- actually this should be a feature of the glog package. Would be awesome to do:
Followup: glog is an opensource copy of a google-internal library; there's already something enabling this internally; we'll try to get a new version pushed externally in the next week or so. Then we can fix this.
Awesome. On Oct 31, 2014 2:53 PM, "Daniel Smith" wrote:
should meet your requirements.
+1, I would love to have this.
Change:
}, } r := &Reflector{ <del> name:                   "test-reflector", listerWatcher:          lw, store:                  NewFIFO(MetaNamespaceKeyFunc), initConnBackoffManager: bm, clock:                  fakeClock, watchErrorHandler:      WatchErrorHandler(DefaultWatchErrorHandler), </del> <ins> name:              "test-reflector", listerWatcher:     lw, store:             NewFIFO(MetaNamespaceKeyFunc), backoffManager:    bm, clock:             fakeClock, watchErrorHandler: WatchErrorHandler(DefaultWatchErrorHandler), </ins> } start := fakeClock.Now() err := r.ListAndWatch(stopCh)

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
} pvLister = append(pvLister, pv) } } return pvLister }

Discussion:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.
Change:
if hosts.Len() > 1 { return } <del> time.Sleep(time.Duration(svcSessionAffinityTimeout) * time.Second) </del> <ins> // In some case, ipvs didn't deleted the persistent connection after timeout expired, // use 'ipvsadm -lnc' command can found the expire time become '13171233:02' after '00:00' // // pro expire state       source             virtual            destination // TCP 00:00  NONE        10.105.253.160:0   10.105.253.160:80  10.244.1.25:9376 // // pro expire state       source             virtual            destination // TCP 13171233:02 NONE        10.105.253.160:0   10.105.253.160:80  10.244.1.25:9376 // // And 2 seconds later, the connection will be ensure deleted, // so we sleep 'svcSessionAffinityTimeout+5' seconds to avoid this issue. // TODO: figure out why the expired connection didn't be deleted and fix this issue in ipvs side. time.Sleep(time.Duration(svcSessionAffinityTimeout+5) * time.Second) </ins> } } framework.Fail("Session is sticky after reaching the timeout")

Discussion:
Which jobs are flaking: https://k8s- Which test(s) are flaking: Services should have session affinity timeout work for service with type clusterIP Services should have session affinity timeout work for NodePort service We have other flaky cases, like , that should also bu resolved. But cases also run in , so I suggest we solve this problem first. Testgrid link: https://k8s- Reason for failure: In ipvs mode, we set session affinity timeout as 125s, the test case is: run host command to send a request, mark returned hostName 125s another request, if return different hostName, test succed. I think the reason is, in the second request, ipvs connection may still in sessionAffinity, send another request will result in seffinity restart count, eventually result in this test case flaky.
/sig network /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved
This keeps failing https://k8s-