jiebi/CodeConvo huggingface dataset:
Change:
return nil } <del> ret, err := podClient.Create(pod) if err != nil { framework.ExpectNoError(err, "Failed to create %q pod: %v", pod.GetName(), err) } </del> <ins> // Creating the pod can fail initially while the service // account's secret isn't provisioned yet ('No API token found // for service account "csi-service-account", retry after the // token is automatically created and added to the service // account', see https://github.com/kubernetes/kubernetes/issues/68776). // We could use a DaemonSet, but then the name of the csi-pod changes // during each test run. It's simpler to just try for a while here. podClient := f.PodClient() ret := podClient.CreateEventually(pod) </ins> // Wait for pod to come up framework.ExpectNoError(framework.WaitForPodRunningInNamespace(client, ret))

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:
"STANDARD_D3":            16, "STANDARD_D32AS_V4":      32, "STANDARD_D32A_V4":       32, <ins> "STANDARD_D32DS_V4":      32, "STANDARD_D32D_V4":       32, </ins> "STANDARD_D32S_V3":       32, "STANDARD_D32_V3":        32, "STANDARD_D3_V2":         16,

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
// wait for node to finish processing (should terminate and not time out) } } <ins> func TestNodeUpdateRetryTimeout(t *testing.T) { for _, tc := range []struct { count int want  time.Duration }{ {count: 0, want: 250 * time.Millisecond}, {count: 1, want: 500 * time.Millisecond}, {count: 2, want: 1000 * time.Millisecond}, {count: 3, want: 2000 * time.Millisecond}, {count: 50, want: 5000 * time.Millisecond}, } { t.Run(fmt.Sprintf("count %d", tc.count), func(t *testing.T) { if got := nodeUpdateRetryTimeout(tc.count); got != tc.want { t.Errorf("nodeUpdateRetryTimeout(tc.count) = %v; want %v", got, tc.want) } }) } } </ins>

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:
"port": 10001, "labels": { "name": "redisslave" <del> } </del> <ins> }, </ins> "selector": { "name": "redisslave" }

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: not fixed the SMB mount issue totally, when there is a SMB mount with same remote path, original SMB mapping would be removed and SMB mapping re-established, that would cause temporally data inaccessible with the original container. should change to should use to check whether original smb mapping is valid, here is an example showing that after SMB server password changed, could validate whether connection is ok: the main diff on smb mount between linux and windows is that on LInux, every smb mount is independent, while on Windows, one remote smb server address(e.g. ) can only have one SMB-GlobalMapping. So on Windows, there is a difficulty: in some cases, we should skip create SMB-GlobalMapping since it already exists in other cases, original password is incorrect or expired, user wants to delete SMB-GlobalMapping, and then create a new SMB-GlobalMapping (fixed by ) On Windows, there is no way to check whether original SMB-GlobalMapping is valid or not, that was the answer about 1 years ago from windows team, will update this thread(also about the max SMB-GlobalMapping limit) if there is any new update recently. What you expected to happen: How to reproduce it (as minimally and precisely as possible): 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 storage /assign

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-aks-engine-azure-master-windows-2004 Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance] Since when has it been failing: since enabling the Windows 2004 SAC release tests Testgrid link: Reason for failure: The manifest for is missing the new windows server version 2004. This has occurred before: I looks like we need someone with appropriate permissions to update the manifests once the images are ready. Anything else we need to know: There was some work done in to automate some of this. Is there something missing? There are a few other tests that are failing in this job but should be covered by updating /cc /sig windows
The test passed 2x consecutively. We can close this now. /close
Closing this issue. <detailsIn response to : The test passed 2x consecutively. We can close this now. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
package network import ( <ins> "context" </ins> "fmt" "strings" "time"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: n/a Which test(s) are failing: "should resolve connection reset issue [Slow]" Since when has it been failing: it never worked Testgrid link: n/a Reason for failure: The image used for the test is using only IPv4 Anything else we need to know: We should: [x] refactor the code to support IPv6 [ ] ~consolidate the image in agnhost~ [x] configure an IPv6 job to test network https://k8s-,%20IPv6,%20master
/assign /sig-network
GitHub didn't allow me to assign the following users: Billy99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /sig-network 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 network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
/help wanted
/help wanted /good-first-issue
/remove-good-first-issue the agnhost promotion process is not something easy for new contributors
Hi, I would like to contribute to this.
good, thanks
sorry , I needed to fix it and I took over, thanks for stepping up /assign /remove help-wanted
OK.Yesterday I have refactor the code to support IPv6, but I understand wrong about consolidate the image in agnhost. I'm sorry for not being able to help.
no worries, it was trickier than I thought, thanks again for your help
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
--image "${MASTER_IMAGE}"  --tags "${MASTER_TAG}"  --network "${NETWORK}"  <del> --scopes "storage-ro" "compute-rw"  </del> <ins> --scopes "storage-ro,compute-rw"  </ins> --can-ip-forward  --metadata-from-file  <del> "startup-script=${KUBE_ROOT}/cluster/gce/configure-vm.sh"  "kube-env=${KUBE_TEMP}/master-kube-env.yaml"  --disk name="${MASTER_NAME}-pd" device-name=master-pd mode=rw boot=no auto-delete=no </del> <ins> "startup-script=${KUBE_ROOT}/cluster/gce/configure-vm.sh,kube-env=${KUBE_TEMP}/master-kube-env.yaml"  --disk "name=${MASTER_NAME}-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no" </ins> } # TODO(dawnchen): Check $CONTAINER_RUNTIME to decide which

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
if err != nil { return err } <ins> type unidentifiedContainer struct { // Docker ID. id string // Docker container name name string } unidentifiedContainers := make([]unidentifiedContainer, 0) </ins> uidToIDMap := map[string][]string{} for _, container := range containers { _, uid, name, _ := dockertools.ParseDockerName(container.Names[0]) <ins> if uid == "" && name == "" { unidentifiedContainers = append(unidentifiedContainers, unidentifiedContainer{ id:   container.ID, name: container.Names[0], }) continue } </ins> uidName := string(uid) + "." + name uidToIDMap[uidName] = append(uidToIDMap[uidName], container.ID) } <ins> // Remove all non-running unidentified containers. for _, container := range unidentifiedContainers { data, err := kl.dockerClient.InspectContainer(container.id) if err != nil { return err } if data.State.Running { continue } glog.Infof("Removing unidentified dead container %q with ID %q", container.name, container.id) err = kl.dockerClient.RemoveContainer(docker.RemoveContainerOptions{ID: container.id}) if err != nil { return err } } // Evict dead containers according to our policies. </ins> for _, list := range uidToIDMap { if len(list) <= kl.maxContainerCount { continue

Discussion:
W0312 15:24:56. 792 ] found a container with the "k8s" prefix, but too few fields (5): "k8scadvisor.8d424740cadvisor-" These are all brand new pods - they should not be invalid
I've been tracking this issue, this seems to be old, not new containers. Typically happens when a GCE cluster is started (static pods are brought up by the old Kubelet) when the new Kubelet comes up it kills the old pods but we can't GC them because we can't recognize them. The log is from GC. Assigning to myself and I'll fix today.
dup of ?
Thanks closed that in favor of this. , Dawn Chen wrote:
thanks for handling this. Let me know if there's anything I can help. We should GC them as long as the container name starts with k8s.
I saw it today on a brand new cluster. On Mar 12, 2015 12:58 PM, "Yu-Ju Hong" wrote:
that should be expected. The first Kubelet that comes up is the Kubelet we have built-in the Container VM image and it doesn't do the new names yet.
No, it keeps happening, even later. I manually updated kubelet, it keeps popping up On Mar 12, 2015 1:10 PM, "Victor Marmol" wrote:
taking a look
indicates what happened above: 1) When node first bootstrap, it has containers running with old format 2) kubelet is upgrade, and kill old containers 3) GC periodically queries the dead containers with k8s prefix, and found those containers with old format, and throw log message. How to fix? just GC them.
Or simply lower down the log level to VLOG(4) since it should be a short-term thing.
Just sent out with the fix. The issue was container GC. Old Kubelet created containers New Kubelet comes up and kills old containers GC runs, but since the containers don't have a UID we don't remove them (repeat) Verified on a new cluster.
Change:
return tabbedString(func(out io.Writer) error { w := NewPrefixWriter(out) w.Write(LEVEL_0, "Name:t%vn", ing.Name) <ins> printLabelsMultiline(w, "Labels", ing.Labels) </ins> w.Write(LEVEL_0, "Namespace:t%vn", ing.Namespace) w.Write(LEVEL_0, "Address:t%vn", loadBalancerStatusStringer(ing.Status.LoadBalancer, true)) def := ing.Spec.DefaultBackend

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
redirectWant: "http://example.com/redirected/target/", forwardedURI: "/proxy/node/node1:10250/redirect", }, <ins> "redirect abs use reqHost no host no scheme": { sourceURL:    "http://mynode.com/redirect", transport:    emptyHostAndSchemeTransport, redirect:     "http://10.0.0.1:8001/redirected/target/", redirectWant: "http://10.0.0.1:8001/proxy/node/node1:10250/redirected/target/", forwardedURI: "/proxy/node/node1:10250/redirect", reqHost:      "10.0.0.1:8001", }, </ins> "source contains the redirect already": { input:        `<pre><a href="kubelet.log">kubelet.log</a><a href="http://foo.com/proxy/node/node1:10250/google.log">google.log</a></pre>`, sourceURL:    "http://foo.com/logs/log.log",

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
if err == nil { t.Fatalf("Random doesn't support fieldValidation, yet no error found") } <ins> err = fieldValidationVerifier.HasSupport(schema.GroupVersionKind{Group: "", Version: "v1", Kind: "List"}) if err == nil { t.Fatalf("List does not support fieldValidation, yet no error found") } </ins> } type EmptyOpenAPI struct{}

Discussion:
kubectl apply performs validation before the apply. Non-CRD resources (e.g. pods / deployments) don't need CRD schema for validation, but if we use resource, kubectl calls . In my Kubernetes cluster, administrator doesn't allow users to list CRDs, so user cannot apply non-CRD resources (e.g. pods / deployments) with resource. doesn't happen because we're going to apply two Deployments. should not happen because we're going to apply two Deployments. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted /assign
/priority backlog
Change:
continue } if lp.Protocol == "udp" { <del> isIPv6 := svcInfo.clusterIP.To4() != nil </del> <ins> isIPv6 := utilproxy.IsIPv6(svcInfo.clusterIP) </ins> utilproxy.ClearUDPConntrackForPort(proxier.exec, lp.Port, isIPv6) } replacementPortsMap[lp] = socket

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: There is a bug in ipv6, see: What you expected to happen: The judgement logic should be: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig network /area ipv6
/assign cc
Change:
mock := newMockLister(c.successes, c.failures, v1alpha1.InitializerConfigurationList{}, t) manager := NewInitializerConfigurationManager(mock) manager.interval = 1 * time.Millisecond <del> manager.Run(mock.stopCh) <-mock.stopCh </del> <ins> for i := 0; i < 1+c.successes+c.failures; i++ { manager.sync() } </ins> _, err := manager.Initializers() if err != nil && c.expectReady { t.Errorf("case %s, expect ready, got: %v", c.name, err)

Discussion:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.
Change:
) // serviceConfig is a deserialized form of the config file format which ConfigSourceFile accepts. <ins> // TODO: this is apparently untested; is it used? </ins> type serviceConfig struct { Services []struct { Name      string   `json: "name"` Port      int      `json: "port"` Endpoints []string `json: "endpoints"` <del> } `json: "service"` </del> <ins> } `json:"service"` </ins> } // ConfigSourceFile periodically reads service configurations in JSON from a file, and sends the services and endpoints defined in the file to the specified channels.

Discussion:
For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.
Change:
type updateNamespaceFunc func(kubeClient clientset.Interface, namespace *api.Namespace) (*api.Namespace, error) // retryOnConflictError retries the specified fn if there was a conflict error <ins> // it will return an error if the UID for an object changes across retry operations. </ins> // TODO RetryOnConflict should be a generic concept in client code func retryOnConflictError(kubeClient clientset.Interface, namespace *api.Namespace, fn updateNamespaceFunc) (result *api.Namespace, err error) { latestNamespace := namespace

Discussion:
See for full dumps. The line number of corresponds to:
From a quick look, perhaps the namespace object returned from retryOnConflictError() just above no longer has a DeletionTimestamp and thus "*namespace.DeletionTimestamp" triggers the panic?
Thanks for the report, I will investigate.
Change:
# See the License for the specific language governing permissions and # limitations under the License. <del> ARG BASEIMAGE </del> ARG RUNNERIMAGE <del> FROM ${BASEIMAGE} as debbase </del> FROM ${RUNNERIMAGE} <del> # This is a dependency for `kubectl diff` tests COPY --from=debbase /usr/bin/diff /usr/local/bin/ COPY --from=debbase /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu COPY --from=debbase /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu COPY --from=debbase /lib64/ld-linux-x86-64.so.2 /lib64 </del> COPY cluster /kubernetes/cluster COPY ginkgo /usr/local/bin/ COPY e2e.test /usr/local/bin/

Discussion:
N/A 07/18 02:38 PDT No response /sig release
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
Slack thread:
/sig cli