jiebi/CodeConvo huggingface dataset:
Change:
if template.Spec.RestartPolicy != api.RestartPolicyAlways { allErrs = append(allErrs, field.NotSupported(fldPath.Child("spec", "restartPolicy"), template.Spec.RestartPolicy, []string{string(api.RestartPolicyAlways)})) } <ins> if template.Spec.ActiveDeadlineSeconds != nil { allErrs = append(allErrs, field.Invalid(fldPath.Child("spec", "activeDeadlineSeconds"), template.Spec.ActiveDeadlineSeconds, "must not be specified")) } </ins> } return allErrs }

Discussion:
setting activeDeadlineSeconds in deployment pod template, and seen new pods are continuously created after the older one dies. Is this excepted? if not we should forbidden this.
Yes, it is expected. Once a pod dies, the replica set controller will spawn a new one. activeDeadlineSeconds doesn't make any sense when used under a controller.
we may want to make it a validation error, but I don't feel strong.
Yes, we should not allow activeDeadlineSeconds for restartPolicy=Always pods generally.
What if I want a container to be restarted no matter what status it exits with, but to give up trying if it cannot even start up in seconds? So like this: Start a pod if it keeps constantly failing for seconds: stop it else (if it managed to start and not fail in those first seconds from creating): restart it everytime it fails or successfully finishes
then you want your own controller, RCs are designed for a simple use case: long-running apps. Have a look in , though keep in mind they are under a major redesign:
Sorta late to the party, but this behavior stops us from being able to use a Deployment to mitigate a production memory leak. Our application can handle a , but a leaves items in a pending state for our customers. Killing pods on a regular basis through kubernetes would allow us to induce known behavior of a graceful termination versus deploying new code to handle a timer before terminating. While I understand the intention of this feature, I feel that as a mitigation tool while my teams track down the memory leak, this would let my oncall rotation sleep easy.
Change:
} func (rl *respLogger) AddKeyValue(key string, value interface{}) { <ins> rl.mutex.Lock() defer rl.mutex.Unlock() </ins> rl.addedKeyValuePairs = append(rl.addedKeyValuePairs, key, value) }

Discussion:
Apiserver crashed with stacktrace: Not to crash I was able to reproduce it by "slowing down" deleting headers in Authentication filter (): And making requests (around 5-10 requests to trigger this race condition): Crash was caused by race condition - one goroutine was modifying headers of requests (for example authentication filter). The other goroutine was trying to get UserAgent from request, which is also taken from request's headers map. This causes unrecoverable panic. <detailsAll versions, tested on 1.21 </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /priority important-soon
/triage accepted
Reopening - since we need to cherrypick it to previous releasses.
- friendly ping on opening cherrypicks
I've opened two cherry-picks:
One more for 1.20:
All merged - thanks!
Change:
Type=oneshot RemainAfterExit=yes ExecStartPre=/usr/bin/mkdir -p /opt/cni <del> ExecStartPre=/usr/bin/curl --fail --silent --show-error --location --create-dirs --output /opt/downloads/cni.tar.gz https://storage.googleapis.com/kubernetes-release/network-plugins/cni-9d5e6e60e79491207834ae8439e80c943db65a69.tar.gz </del> <ins> ExecStartPre=/usr/bin/curl --fail --silent --show-error --location --create-dirs --output /opt/downloads/cni.tar.gz https://storage.googleapis.com/kubernetes-release/network-plugins/cni-07a8a28637e97b22eb8dfe710eeae1344f69d16e.tar.gz </ins> ExecStart=/usr/bin/tar xf /opt/downloads/cni.tar.gz -C /opt/cni/ - name: kubernetes-install-docker2aci.service

Discussion:
I have a container that got the broadcast address of podCIDR subnet. My CNI conf is: And the container in question has which is the broadcast address for the subnet. So it can't figure out the MAC of cbr0 because all frames are getting sent to (or at least, that's what seems to indicate). Eg: tcpdump alonside a wget on vs a similar normal container
Looks like a bug in ipam. Will try to put together a fix.
I stress tested your fix overnight with the networking suite I'm writing (the one that found the bug), didn't hit the failure in 100 runs, we should get it in asap
Great. It would be better to pull from upstream once the fix is merged. Otherwise, we have to fork it like we did in 1.3.
Marking this p0 flake so it shows up in release queries
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Change:
// inherited features from apiextensions-apiserver, relisted here to get a conflict if it is changed // unintentionally on either side: apiextensionsfeatures.CustomResourceValidation: {Default: true, PreRelease: utilfeature.Beta}, <del> SupportIPVSProxyMode:                           {Default: false, PreRelease: utilfeature.Alpha}, </del> }

Discussion:
There are some work to be done in the follow-up of , that is, help IPVS existing alpha. [x] GCE CI failures()[x] cross-node visit NodePort ()[x] hairpin issue ()[x] Using ipset doing snat and packet filtering and reduce iptables call().[x] automatically load kernel modules. (, )[x] creating e2e test suite for IPVS in upstream CI ().[x] ip cmd -netlink bind/unbind IP address to/from dummy device()[x] rsync to HEAD of iptables(, )[x] enable flush batch API()[x] Fix TODOs in codes ()[x] Bug report (, )[x] Default sync period()[x] IPV6 support(, and more...) /cc
/cc
ref ! It will generate annoy error info If unbind multi-ports on one service .
You're right. I think it's a nice finding. Can you fire a PR to fix it?
Sure, I'll make it soon.
I found it is treated as already bound if returned 2 in , but ref to the and of ip , it just means an error was reported by the kernel, such as "Operation not permitted". I prefer to use instead of command to manage ip address.
Actually, I have considered to use netlink before. I think what you said make sense, but can we discuss it in other thread? I mean, create a new issue and link it here? Thanks!
I opened a issue
on the subject :)
OOPS... I will fix that typo. Thanks
Wish to use ipset to replace KUBE-MARK-MASQ chain.
I find it's a reasonable suggestion and am trying to make it workable...
There are to ways to add IPVS CI job: , but doesn't support any kube-proxy config right now, so I had this pr , and also, need support it too, see this pr: kubernetes/kubernetes-anywhere build cluster. See this pr: kubernetes/test-infra The second way is much easier and faster, but I was told they gonna deprecated the , so in the long term, we still need and 's support. If anybody have better way or have some suggestion about this, please let me know, I'll be really appreciate, Thanks.
This one is done as both PRs are merged:
ACK!

/area ipvs
We are almost reaching the beta, except GCE CI failures, see The failure is the case that, visiting Cluster IP from Pod A, and the backend Pod B is in the same host with the Pod A. Pod A failed to get response from Pod B until timeout. I can reproduce the failures in my GCE cluster with kubent as network plugin, but it works fine in my local-up cluster and people has never reported the issue yet. and I are digging...
IPVS CI is green now.
Change:
return true } <del> func (ca *cloudCIDRAllocator) canRetry(nodeName string) bool { </del> <ins> func (ca *cloudCIDRAllocator) retryParams(nodeName string) (bool, time.Duration) { </ins> ca.lock.Lock() defer ca.lock.Unlock() <del> count := ca.nodesInProcessing[nodeName].retries + 1 </del> <ins> entry, ok := ca.nodesInProcessing[nodeName] if !ok { glog.Errorf("Cannot get retryParams for %q as entry does not exist", nodeName) return false, 0 } count := entry.retries + 1 </ins> if count > updateMaxRetries { <del> return false </del> <ins> return false, 0 </ins> } ca.nodesInProcessing[nodeName].retries = count <del> return true </del> <ins> return true, nodeUpdateRetryTimeout(count) } func nodeUpdateRetryTimeout(count int) time.Duration { timeout := updateRetryTimeout for i := 0; i < count && timeout < maxUpdateRetryTimeout; i++ { timeout *= 2 } if timeout > maxUpdateRetryTimeout { return maxUpdateRetryTimeout } return timeout </ins> } func (ca *cloudCIDRAllocator) removeNodeFromProcessing(nodeName string) {

Discussion:
/kind bug /sig network What happened: Networking tight loop causing GCP Cloud rate limiting to kick in. Causing tests to fail. Suspected call stack: Looks like it could be the root cause of these test failures here: https://k8s- These storage tests are hitting rate limit on the cloud api when trying to detach/delete disks. However, we have exponential backoff for all these functions. But the rate limiting from an external source is affecting the tests. See logs snippet: Note: These logs span exactly 1 minute. Try grepping "rateLimit" or "CIDRNotAvailable" -also note that the CIDRNotAvailable error messages are probably not verbose enough as they do not pinpoint what the actual error is, you can only associate them by correlation in timing and then looking at the code. Shorter snippet from above log file to demonstrate: since this is running on hundreds of nodes hitting this API call should involve some sort of exponential backoff as well as jitter. /cc /assign
/assign
/assign
/sig cloud-provider /sig gcp /milestone v1.12 (since is marked as v1.12)
may we have a priority on this since Code Freeze is next week? :)
Quick question, are we using the default API rate limits quota for scalability projects?
I will defer to for priority because he probably has the most context on how serious this is and what it could affect
Which rate limit are you referring to? (I don't remember us changing it any time) Btw - this is the project being used for that job -
I put up a patch for adding exponential retry
Gentle reminder that for this to be considered for 1.12 past Code Freeze, which is next week, it must have a status/critical-urgent label. I see this is being actively worked on
Change:
if !supportedOutputTypes.Has(o.Output) { return fmt.Errorf("--output %v is not available", o.Output) } <ins> supportedSortTypes := sets.NewString("", "name", "kind") if len(o.SortBy) > 0 { if !supportedSortTypes.Has(o.SortBy) { return fmt.Errorf("--sort-by accepts only name or kind") } } </ins> return nil }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a sort parameter (or similar concept) to the command. Why is this needed: With the numerous amount of API resources (not counting custom ones), it is sometimes difficult locating them in the output. By default, API resources are not sorted by the name column (the first on the left) and often this is the column holding the information one wishes to query. A sort parameter would help more easily identify the object to be understood.
/sig usability
Change:
import ( "context" <ins> "encoding/json" "fmt" </ins> "testing" "time"

Discussion:
Why PatchService method is used for deleting finalizers in cloud-controller-manager, This method updates with service/status, It seems to go unnoticed by the API server, resulting in the API server being unaware when the finalizer field on the service is deleted, leading to a delay in the release of service-related NodePorts. service nodeport be released promptly when service is deleted. create a loadblancer service with nodeport seted,then delete it and recreate. cloud-controller-manager add a finalizer on service. delete this service and then cloud-controller remove finalizer. but nodeport is not released when service deleted. ref i change like this, it seems like releasing nodeport when service is deleted : No response <details</details<details</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 cloud-provider
Are you sure? that method updates the status and remove the finalizer ... otherwise , who removes the finalizer?
I apologize for any confusion. What I meant was that the update of the status and the removal of the finalizer are performed through updating service/status. Therefore, removing the finalizer does not release resources.It seems like removal of the finalizer by service/status, store.AfterDelete is nil. i think remove the finalizer should by patch servcie and updates the status should by patch service/status.Now we patch both by servcie/status.
no need to apologize, let me see if I can reproduce this locally first, Services api allocation is complex , it overrides the standard AfterDelete and release all allocated resources there /assign
/sig network ack the problem
will look for a possibly-related past cloud provider issue.
this will be fixed by , it is a problem in the apiserver logic
Cool! I forgot that you can patch finalizers thru /status. I repro'ed it on both ClusterIP and NodePort.

Saw this in the logs: So the repair loop, yet again, saves our butt but also hides a bug.
we need metrics here about to have visibility of the repairs
I also found this problem in versions 1.23 and 1.27
yep, I started the backports , but we can only backport to the supported versions, 1.23 and 1.24 are EOL
Change:
tags = ["automanaged"], visibility = ["//visibility:public"], ) <ins> go_test( name = "go_default_test", srcs = ["types_test.go"], embed = [":go_default_library"], deps = ["//vendor/github.com/google/go-cmp/cmp:go_default_library"], ) </ins>

Discussion:
What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after
Change:
} func TestProxyUpdatePort(t *testing.T) { <del> port, err := echoServer(t, "127.0.0.1:0") if err != nil { t.Fatal(err) } </del> lb := NewLoadBalancerRR() lb.OnUpdate([]api.Endpoints{{JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}})

Discussion:
https://travis-
Looking.
Another instance, or a different thing? https://travis-
Change:
t.Fatalf("%s: Expected success, got %v", protoStr, err) } <del> if string(buffer.Bytes()[:len(output)]) != output { t.Errorf("%s: Expected output '%s', got '%v'", protoStr, output, buffer.Bytes()) </del> <ins> if string(buffer.Bytes()) != output { t.Errorf("%s: Expected output '%s', got '%v'", protoStr, output, string(buffer.Bytes())) </ins> } if fcmd.CombinedOutputCalls != 2 {

Discussion:
On some systems, iptables-save outputs the following warning to stderr: Note that the error message includes a newline. Because kube-proxy captures both stdout and stderr when calling , the newline might cause rules to be garbled. For example, the output might contain the following line: The parser treats this as a chain line, and panics, as predicted in
/sig network
FYI
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Just FYI here's another example of garbled output:
Anyway, fix is in Please review.
/assign
/remove-triage unresolved
Change:
klog.V(4).InfoS("Pod cannot start ever", "pod", klog.KObj(update.Options.Pod), "podUID", podUID, "updateType", update.WorkType) return ctx, update, canStart, canEverStart, true case !canStart: <ins> // this is the only path we don't start the pod, so we need to put the change back in pendingUpdate status.pendingUpdate = &update.Options </ins> status.working = false klog.V(4).InfoS("Pod cannot start yet", "pod", klog.KObj(update.Options.Pod), "podUID", podUID) return ctx, update, canStart, canEverStart, true

Discussion:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?
Change:
export PATH=${GOPATH}/bin:${PWD}/third_party/etcd:/usr/local/go/bin:${PATH} <del> retry go get github.com/tools/godep && godep version </del> retry go get github.com/jstemmer/go-junit-report # Enable the Go race detector.

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
allPorts = append(allPorts, fmt.Sprintf("%v:%v", a.IPProtocol, p)) } } <ins> // Sort all slices to prevent the event from being duped sort.Strings(allPorts) </ins> allow := strings.Join(allPorts, ",") <ins> sort.Strings(fw.SourceRanges) </ins> srcRngs := strings.Join(fw.SourceRanges, ",") <ins> sort.Strings(fw.TargetTags) </ins> targets := strings.Join(fw.TargetTags, ",") return fmt.Sprintf("--description %q --allow %v --source-ranges %v --target-tags %v --project %v", fw.Description, allow, srcRngs, targets, projectID) }

Discussion:
/kind bug /sig network /assign What happened: For events being generated within the GCE cloudprovider, slices of firewall parameters are not being sorted before converted into a string. Due to random ordering, this may result in the same line being repeated.
Change:
- apiGroups: - "" resources: <ins> - nodes verbs: - delete - patch - update - apiGroups: - "" resources: </ins> - events verbs: - create

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubelet RBAC Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCE Install tools: make quick-release && go run -up What happened: I upgraded the cluster with After which the master node was not ready. What you expected to happen: I expected the master node to be ready. How to reproduce it (as minimally and precisely as possible): Anything else we need to know: In the api server logs: In the kubelet logs:
cc since you were running into this.
cc
c.f. it seems wrong for the node to delete itself
In the case where a kubelet starts up and sees a mismatch between the externalid field and its own idea of what its external id is, it is trying to delete itself. Questions I have: what can make the external id mismatch occur (in cloudprovider and non-cloudprovider cases)? is it even safe for a kubelet to summarily delete itself (as it is trying to do today), or can that mess up apiserver/controller logic around node cleanup, like the attach/detach controller, etc? can we limit the node to reporting the mismatch by updating node status and stay in the tryRegisterWithApiServer loop, and let something like the node controller remove a node that gets in this situation instead? cc
happens in both GCE and GKE upgrades. who can update node status. I would view this as strictly worse than giving kubelets node delete privileges.
If a node instance is recreated with the same name, it will register as the same node. This apparently also happens in tests (). AFAIK, attach/detach controller annotates the node object to keep states. If the node is backed by a new (VM) instance, it is probably safe/better to recreate the node object and start afresh. Of course, upon any node update/delete/add events, the detach/attach controller should examine and reconcile the status. Hm......AFAIK node controller also does not coordinate with other controllers (e.g., detach/attach). I am not sure how this would help the second point you made.

would you be ok with adding delete permissions for kubelet because it has them and uses them today, and then taking the argument about whether it should be done another way to it's own issue?
yeah, convinced me that if the node is the authority of the spec during self-registration cases, update/delete permissions are reasonable, and we'd need to figure out how to scope those to update/delete self in the future, just like we do for update status
see