jiebi/CodeConvo huggingface dataset:
Change:
initializing := false for i := range pod.Status.InitContainerStatuses { container := pod.Status.InitContainerStatuses[i] <ins> restarts += int(container.RestartCount) </ins> switch { case container.State.Terminated != nil && container.State.Terminated.ExitCode == 0: continue

Discussion:
The output looks like below: What is expected behavior? Does restart counter should increase when init containers are failing? Does restart counter should be reseted when InitContainer will start work and normal containers start? cc
Restarts are tracked per container - I'd be concerned that the restarts the user is concerned with don't map exactly to the init container restarts, although knowing how many attempts to init have been made are useful. Since init containers are processed serially, when an init container passes, do we reset the restart count to zero? I think we could show the current init container restart count (if pod is in init) in this field. But once the init container succeeds it has to drop back to zero.
For normal containers field shows the sum of from containers status. I think for init containers as we know which container is running (when is merged) we can show restart count for current init container. For normal containers behavior should not change. So it would look like these: First init container is failing Second init container is failing Normal container is failing For better readability we may also add word like in status: Second init container is failing What do you think?
Yeah, although I don't know that we need the Init prefix in the status. I think users can reasonably be expected to infer that RESTARTS is subordinate to STATUS. The init prefix makes it harder to read without adding a ton. , Łukasz Oleś wrote:
Ah, I messed up. shows status of normal containers. in Status shows status of init containers: I think this part should be always showed. So it will look like these: What do you think?
Ok, I decided to use the same approach as for normal containers. RESTARTS just shows sum of all init containers restarts.
Fix is merged
Change:
return nil, fmt.Errorf("Source range restrictions are not supported for openstack load balancers without managing security groups") } <del> affinity := v1.ServiceAffinityNone </del> <ins> affinity := apiService.Spec.SessionAffinity </ins> var persistence *v2pools.SessionPersistence switch affinity { case v1.ServiceAffinityNone:

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Creating service(type: LoadBalancer, sessionAffinity: ClientIP), service has no affinity. What you expected to happen: The service has affinity How to reproduce it (as minimally and precisely as possible): a service, its yaml as following: kind: Service apiVersion: v1 metadata: labels: app: application name: application spec: type: LoadBalancer ports: port: 80 targetPort: 9091 sessionAffinity: ClientIP selector: app: application request from Neutron, check the value of "Persistence" Anything else we need to know?: Kubernetes's OpenStack cloudprovider can't set persistence to "SOURCE_IP". Environment: Kubernetes version (use ): kubernetes 1.6.4
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig network
/assign
Fixed in /close
Change:
f *framework.Framework, sa *v1.ServiceAccount, ) *v1.Pod { <del> podClient := client.CoreV1().Pods(config.Namespace) </del> priv := true mountPropagation := v1.MountPropagationBidirectional hostPathType := v1.HostPathDirectoryOrCreate

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The code creates a pod directly, without waiting for the service account secret to be available. Depending on timing, this can fail with a error. What you expected to happen: It should use a DaemonSet instead, then the daemon set controller will ensure that the pod gets created eventually. [Edit: when implementing the fix, I found it easier and less intrusive to just retry pod creation.] How to reproduce it (as minimally and precisely as possible): It's not possible to trigger the failing race condition reliably. I've seen it a few times on my own cluster. Anything else we need to know?: Originally discussed in and in the CSI working group meeting on Monday, September 17th ().
/sig storage
Change:
"net/http" "net/http/httptest" "reflect" <ins> "regexp" </ins> "strings" <ins> "sync" </ins> "testing" <ins> "time" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" )

Discussion:
Related with issue , the API server should have a cap on the number of outstanding operations/requests it's handling, and return an error otherwise. A simple semaphore is an idea for this.
+1 !
The good news/bad news on this is that there is a rate limiter in the API server (), but the defaults for it seem too high: 10 qps average, 200 burst (). We could start by lowering the burst level to something smaller, like 30. It may be interesting to also differentiate between GET and PUT/POST requests.
I think that we need limits on the number of outstanding requests, not the number of QPS.
-An max outstanding would be useful. But it may force us to have separate buckets for different types of requests, i.e. a small number of long running requests causing API server to reject short requests. -Heard that you might be looking into adding support for flow control (or something like it?). We may need it soon to help avoid bugs like runaway node status updates (see issue ).
I had not - the things we were looking at were the bastion changes to apiserver which will break logs and proxying into their own rest resources so they can be granularly controlled. Being able to timebox and classify requests differently would be good. ----- Original Message -----
- Ah, np, I probably misheard.
What are our plans for handling this client side? Do we want clients to handle "you're being throttled" error themselves, or do we plan to handle it in the library? I'm asking because currently kubelet does not have a 'short' retry loop, hence it tries to report NodeStatus every X (2) seconds, whether it succeed or not. Neither we have a sidechannel for heartbeat messages. This would mean, that if API server will be under heavy load, and with not-negligible probability NodeStatus reporting will be throttled, we may incorrectly mark a Node as unreachable. Currently it's not a huge problem, because X << Y, where Y is the time we wait before we decide a Node is unreachable. But because of the effort somewhere close to it'll probably get worse.
The client library should have options for retry on client.Config which include the ability to disable the behavior. Automatic retry is probably an "opt-out" behavior.

----- Original Message -----
says there are people working on rate limiting client connections to API server.
I have in the past adjusted the rate limiter to support the creation of large clusters. I also the logic. If you adjust the rate limiter settings, please make sure it is still possible to create large clusters.
I'm closing this as fixed, given the original subject. If we want to expand client-side support for retry, please open a dedicated issue. (Also note that QPS based throttling was to the client recently too)
Change:
}, }, { <del> name: "spec:v4 ip:v4 dualstack:on", </del> <ins> name: "spec:v4 ip:v4 dualstack:on isIPv6Primary:false", isIPv6Primary:          false, </ins> specExpctPrimary:       true, clusterIPExpectPrimary: true, enableDualStack:        true,

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
From v1.24 onwards, you will need to either use one of the other [supported runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) (such as containerd or CRI-O) or use cri-dockerd if you are relying on Docker Engine as your container runtime. For more information about ensuring your cluster is ready for this removal, please <del> see [this guide](/blog/2022/03/31/ready-for-dockershim-removal/). </del> <ins> see [this guide](https://kubernetes.io/blog/2022/03/31/ready-for-dockershim-removal/). </ins> ### Beta APIs Off by Default

Discussion:
has some broken links. These are relative links that work OK in the release blog article but need to be absolute hyperlinks in the release notes. Links in release notes work. Visit Click on all the links. Specifically, “this guide” in (there are some more, this is one example) No response v1.24.0 n/a n/a n/a n/a n/a
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig release and IMO /priority important-soon
Hi Tim, I can help fix this /assign
Change:
#   --boilerplate <string = path_to_kube_codegen_boilerplate> #     An optional override for the header file to insert into generated files. # <ins> #   --extra-peer-dir <string> #     An optional list (this flag may be specified multiple times) of "extra" #     directories to consider during conversion generation. # </ins> function kube::codegen::gen_helpers() { local in_pkg_root="" local out_base="" # gengo needs the output dir must be $out_base/$out_pkg_root local boilerplate="${KUBE_CODEGEN_ROOT}/hack/boilerplate.go.txt" local v="${KUBE_VERBOSE:-0}" <ins> local extra_peers=() </ins> while [ "$#" -gt 0 ]; do case "$1" in

Discussion:
Earlier it was possible to pass flag to while calling script. Now with the new script, is called under which doesnot support any other flags apart from , and . As it can be seen here there is no option to pass flag to conversion-gen Earlier in the script, it was considering all the inputs passed flag is supported by under the hood, but the function in script is not allowing the flag.
/cc
/sig api-machinery
/assign for code generation /triage accepted
/assign
Can you explain why you need this flag? What I found in k/k was that we don't actually need it at all.
You know what, my memory was faulty. We do use it (until I fix that, which is in a development branch, not merged). But we don't use it in any of the "submodule" configs.
A lot of the "magic" behind the conversion logic is very brittle. Can you help me understand where / how this impacts you?
I whipped up a quick patch but have not tested much:
We are using the flag several places in our script On removal of the flag, the autoConvert functions in. files has the error : Althoug I can see the function is already present at . But there is also a comment like Hence, I think there is a need for the in order to use this pkg.
I see. The component-base is something I didn't account for. If you apply the above patch, does the new argument to work for you?
Above patch throws an error for the cases when flag is not passed to function. Instead I followed this approach :
I'd rather not accumulate into a string - can you tell me what error it throws? Note, mine wants Also - is the argument here a dir (e.g. /home/me/src/foo/bar) or a pkg (e.g. ) ? I think it's actually a pkg, right?
You implementation throws error for the cases when we don't specify the option while calling , as shown below: For such cases I am getting following error
It seems to be an old-bash problem. Try this one?
Yes this is working fine.
OK. I'll prep a PR soon.
Thank you
Change:
continue } if secret.Type == v1.SecretTypeServiceAccountToken { <del> tokenContent = string(secret.Data[v1.ServiceAccountTokenKey]) </del> rootCAContent = string(secret.Data[v1.ServiceAccountRootCAKey]) return true, nil }

Discussion:
https://k8s- /sig auth /kind failing-test
Adding a priority to this: /priority important-soon Please raise the priority if you consider this a release blocker. Given the test job, it normally wouldn't be.
It's a test issue. I'm hoping to fix this before 1.13 but I don't consider it a release blocker.
Change:
} oldNodeUnschedulable = node.Spec.Unschedulable } <ins> // NOTE(aaronlevy): NodeReady condition needs to be the last in the list of node conditions. // This is due to an issue with version skewed kubelet and master components. // ref: https://github.com/kubernetes/kubernetes/issues/16961 // TODO: Remove the code after we drop support for v1.0 kubelets lastIndex := len(node.Status.Conditions) - 1 for i := range node.Status.Conditions { if node.Status.Conditions[i].Type == api.NodeReady && i < lastIndex { node.Status.Conditions[i], node.Status.Conditions[lastIndex] = node.Status.Conditions[lastIndex], node.Status.Conditions[i] break } } </ins> return nil }

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 was looking into what tests were enabled for and found that the following tests: are running 1.18. From the output of the tests (): and What you expected to happen: tests to be running against the latest code for 1.19 How to reproduce it (as minimally and precisely as possible): It looks to be caused by the setting: Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig release /sig windows
Change:
}) }) <del> func execSourceipTest(pausePod v1.Pod, serviceAddress string) (string, string) { var err error var stdout string timeout := 2 * time.Minute framework.Logf("Waiting up to %v to get response from %s", timeout, serviceAddress) cmd := fmt.Sprintf(`curl -q -s --connect-timeout 30 %s/clientip`, serviceAddress) for start := time.Now(); time.Since(start) < timeout; time.Sleep(2 * time.Second) { stdout, err = framework.RunHostCmd(pausePod.Namespace, pausePod.Name, cmd) if err != nil { framework.Logf("got err: %v, retry until timeout", err) continue } // Need to check output because it might omit in case of error. if strings.TrimSpace(stdout) == "" { framework.Logf("got empty stdout, retry until timeout") continue } break } framework.ExpectNoError(err) // The stdout return from RunHostCmd is in this format: x.x.x.x:port or [xx:xx:xx::x]:port host, _, err := net.SplitHostPort(stdout) if err != nil { // ginkgo.Fail the test if output format is unexpected. framework.Failf("exec pod returned unexpected stdout: [%v]n", stdout) } return pausePod.Status.PodIP, host } </del> // execAffinityTestForSessionAffinityTimeout is a helper function that wrap the logic of // affinity test for non-load-balancer services. Session afinity will be // enabled when the service is created and a short timeout will be configured so

Discussion:
What would you like to be : The test currently only works on Cloud Providers or environments that set the External IP on nodes, because it is using the framework directly to check the IPs of the pods, using a no-snat-test-proxy to check if the Pods are not using SNAT. However, this can be simplified, removing the no-snat-test-proxy Pod and executing the queries directly in a Pod. Why is this needed: The test should work in all environments, and it's failing https://k8s-,%20master&include-filter-by-regex=NoSNAT
/sig network /help wanted /failing test
/remove kind-feature /kind failing-test
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
/remove kind-feature
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I would like to investigate this problem. /assign
I have filed , how could I verify if my patch fixes the problem?
I run them locally with KIND
Change:
job.Status.Failed = failed if err := jm.updateHandler(&job); err != nil { <del> return false, err </del> <ins> return forget, err </ins> } if jobHaveNewFailure && !IsJobFinished(&job) { // returning an error will re-enqueue Job after the backoff period <del> return false, fmt.Errorf("failed pod(s) detected for job key %q", key) </del> <ins> return forget, fmt.Errorf("failed pod(s) detected for job key %q", key) </ins> } forget = true

Discussion:
This issue was born out of the discussion from and In short: Job controller has an exponential backoff in place when failures happen to a job. As long as the parallelism is one, it's clear when a failure or success happens, the latter clears the backoff. The problem is when parallelism 1, which can lead to situation where the controller can observe successful and failed pod at the same time and won't clear the backoff leading to further retries and longer wait times (see for extensive details about the problem in e2e) Possible solutions: everything as is both success and failure are observed clear the backoff Pros and cons: Ad. 1. Aside from () I wonder if users got affected by it. Does it make sense to fix it at all? Ad. 2. This approach make sense in some situation, but the question arise, should that be controlled by a user. What if I have 9 failures and 1 success (parallelism = 10), should I still clear the backoff? Maybe we should introduce user controller field to set the failure rate in this case.
/cc
(jumping here 'cause forwarded me this). I personally think that the right approach is to reset the back-off as soon we have a successful pod run to complete. Back-off was introduced, at least in our case, to reduce the impact of bad configured PodSpec in Jobs. If in your run you do have some success, it means you've a good config and you just keep trying (not that different that what we did before ). I don't think it's worth asking user finer tune config. is already complex enough. My 2 cents.
cc
I agree with any success should immediately clear the backoff flag, since it shows the job is configured properly and the problem is only temporary. I'll assign it to myself, but anyone is open to submit a PR fixing this.
Hi I started to implement the pod success check in order to clear the backoff delay in case of at least one of the pods succeed. let me know if you are fine with this approach, and then I will go further with unit-tests and end2end tests.
is the rest of the work on this issue getting done for 1.10? Please update, and add approved-for-milestone if this is on track for 1.10.
I updated my change with missing unit-tests and created the PR:
Change:
<ins> #!/bin/bash # Copyright 2015 Google Inc. All rights reserved. # # 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. mkdir -p /etc/google-fluentd/files if [ -z "$FILES_TO_COLLECT" ]; then exit 0 fi for filepath in $FILES_TO_COLLECT do filename=$(basename $filepath) cat > "/etc/google-fluentd/files/${filename}" << EndOfMessage <source> type tail format none time_key time path ${filepath} pos_file /etc/google-fluentd/fluentd-gcp.log.pos time_format %Y-%m-%dT%H:%M:%S tag file.${filename} read_from_head true </source> EndOfMessage done </ins>

Discussion:
We should provide a dockerfile for a pre-configured Fluentd image that can be passed file paths to collect logs from. We'll likely want one for exporting to elasticsearch and one for exporting to Google Cloud Logging, as we have today for the per-node stdout/stderr collectors. How to collect log files from within a container is a question that comes up occasionally (including ), and it provides a strong example of the usefulness of sidecar containers. cc
A controller that keeps one instance of a pod alive on each node would be useful for this. Shall I go ahead and write such a controller?
Would it be? This is intended to run as a sidecar container in a pod with the user's actual application. I think a pod-per-node controller is orthogonal (and is being discussed in and ). I'll create the actual Dockerfile, and a quick example of how to use it.
Sorry, my rush to catch up I think I mis-understood this thread.
Change:
return c, informers } <del> func (f *fixture) runExpectError(deploymentName string) { f.run_(deploymentName, true) </del> <ins> func (f *fixture) runExpectError(deploymentName string, startInformers bool) { f.run_(deploymentName, startInformers, true) </ins> } func (f *fixture) run(deploymentName string) { <del> f.run_(deploymentName, false) </del> <ins> f.run_(deploymentName, true, false) </ins> } <del> func (f *fixture) run_(deploymentName string, expectError bool) { </del> <ins> func (f *fixture) run_(deploymentName string, startInformers bool, expectError bool) { </ins> c, informers := f.newController() <del> stopCh := make(chan struct{}) defer close(stopCh) informers.Start(stopCh) </del> <ins> if startInformers { stopCh := make(chan struct{}) defer close(stopCh) informers.Start(stopCh) } </ins> err := c.syncDeployment(deploymentName) if !expectError && err != nil {

Discussion:
From https://k8s- I've tried to reproduce locally in an endless loop but no failures so far. cc
Investigating.