jiebi/CodeConvo huggingface dataset:
Change:
// catch race conditions introduced by callers updating pod status out of order. // TODO: have KillPod return the terminal status of stopped containers and write that into the //  cache immediately <del> podStatus, err := kl.containerRuntime.GetPodStatus(ctx, pod.UID, pod.Name, pod.Namespace) </del> <ins> stoppedPodStatus, err := kl.containerRuntime.GetPodStatus(ctx, pod.UID, pod.Name, pod.Namespace) </ins> if err != nil { klog.ErrorS(err, "Unable to read pod status prior to final pod termination", "pod", klog.KObj(pod), "podUID", pod.UID) return err } <ins> preserveDataFromBeforeStopping(stoppedPodStatus, podStatus) </ins> var runningContainers []string type container struct { Name       string

Discussion:
My pod completes (success or failure). The IP temporarily is removed on one of the status updates. The IP is persistent . Apply: Watch: The initial 'succeeded' should have the IP still. On older versions: Full pod state, from 1.27: <details</detailsPrior discussion many, see above Tested on kind Linux <details</details<details</details<details</details
/sig network maybe Relevant PRs in 1.27:
cc
/priority important-soon
is about endpointslices, so no related seems related , ping
I can confirm this commit specifically is the culprit (when I build and test the parent commit it works ok): For now I don't know the reason, cc in case you have some ideas. EDIT: when commenting out these it works as before. I suspect this is because the does not have the information which is determined in
I've opened a PR with a fix. PTAL: Additionally, it turns out that the bug causes one more unnecessary request with status update.
This also relates to sig-node: /sig node We talked about this in the SIG Network meeting, looks like you are taking a look: /assign Please let us know what you find, and please let us know if you need any support!
Thank you! I think I have got to the bottom and summarized the findings in the PR description: I would love to move forward with the review :)
the question from SIG Node meeting was - what is the impact of it besides the flickering IP on status. This may help justify the cherry-pick.
do you have some additional insights about the impact?
In our usage we had to handle events on a pod informer differently to account for the fact we may read it in an invalid state if we read at the wrong time. So for us technically it hsa no impact since we worked around it, for others it could be quite severe potentionally
Thanks! Just FYI as demonstrated by experiments on you could also face this situation in case of kubelet restart. So, probably good you put this workaround in place anyway.
/triage accepted People affected by this regression likely will be affected by kubelet restart in a very precise moment. But it is a low probability event so I would advocate to fix the regression by backporting this fix instead of forcing consumers to work around this behavior.
Change:
goodSum += histogram[count] } <del> goodPct := 100 * float64(goodSum) / float64(allCoordinateCount) </del> <ins> goodPct := 100 * float64(goodSum) / float64(numHandsSeen) </ins> t.Logf("good percentage = %v, histogram = %v", goodPct, histogram) <del> if goodSum != allCoordinateCount { </del> <ins> if goodSum != numHandsSeen { </ins> t.Errorf("Only %v percent of the hands got a central count", goodPct) } }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which test(s) are flaking: Testgrid link: While there aren't any visible failures in the above testgrid link, we've observed flaky timeouts downstream. Reason for failure: Test times out Anything else we need to know: We don't have full logs for failed unit tests, so it's hard to pinpoint exactly which test is timing out, but I believe the offending function is this: You will see that the test iterates times: Summing up the hashMax for all four subtests, we see that the function iterates ~34 million times. While the test takes just ~9 seconds on my machine to complete, the CI is probably struggling with it (other tests are running in parallel and iterating 34 million times over a non-trivial loop is very CPU hungry). A successful execution of the unit test on CI takes ~3-4 minutes on average. The test doesn't have any of the usual suspects that can cause a timeout (like <-chan receive, i/o reads, wait.Poll(), time.Sleep(), etc.), so I suspect the large number of iterations to be the culprit. I propose making the unit test smaller and quicker to complete. Hopefully someone who understands shufflesharding better than me can take over :) /sig api-machinery /cc
when run with , the runtime increases significantly: that time is dominated by TestUniformDistribution
The test does a lot of slice appends. Maybe is constraining the allocator? There isn't much else in the test that might be slowed down by : no mutexes, no RNGs, no atomic operations, no channels, etc.
It looks like the buffer is pre-allocated to be the correct size though, so none of those appends should be resulting in allocations?
/triage accepted
BTW, in another branch I tried taking the s out of the test, instead calling with a lambda that writes into at a position selected by an advancing index. The got a little slower!
Change:
"name":       "The name of this port within the service. This must be a DNS_LABEL. All ports within a ServiceSpec must have unique names. This maps to the 'Name' field in EndpointPort objects. Optional if only one ServicePort is defined on this service.", "protocol":   "The IP protocol for this port. Supports "TCP" and "UDP". Default is TCP.", "port":       "The port that will be exposed by this service.", <del> "targetPort": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service", </del> <ins> "targetPort": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service", </ins> "nodePort":   "The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#type--nodeport", }

Discussion:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.
Change:
// actions will only have sandbox ID and not have pod namespace and name information. // Return error if encounter any unexpected error. if checkpointErr != nil { <ins> if checkpointErr != errors.ErrCheckpointNotFound { err := ds.checkpointManager.RemoveCheckpoint(podSandboxID) if err != nil { glog.Errorf("Failed to delete corrupt checkpoint for sandbox %q: %v", podSandboxID, err) } } </ins> if libdocker.IsContainerNotFoundError(statusErr) { glog.Warningf("Both sandbox container and checkpoint for id %q could not be found. "+ "Proceed without further sandbox information.", podSandboxID)

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
deps = [ "//pkg/api/testapi:go_default_library", "//pkg/api/v1:go_default_library", <del> "//pkg/apis/extensions:go_default_library", </del> <ins> "//pkg/apis/extensions/v1beta1:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", ], )

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
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
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?
Change:
}, "dataSource": { "$ref": "#/definitions/io.k8s.api.core.v1.TypedLocalObjectReference", <del> "description": "This field requires the VolumeSnapshotDataSource alpha feature gate to be enabled and currently VolumeSnapshot is the only supported data source. If the provisioner can support VolumeSnapshot data source, it will create a new volume and data will be restored to the volume at the same time. If the provisioner does not support VolumeSnapshot data source, volume will not be created and the failure will be reported as an event. In the future, we plan to support more data source types and the behavior of the provisioner may change." </del> <ins> "description": "This field can be used to specify either: * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot - Beta) * An existing PVC (PersistentVolumeClaim) In order to use VolumeSnapshot object types, the appropriate feature gate must be enabled (VolumeSnapshotDataSource) If the provisioner can support the specified data source, it will create a new volume based on the contents of the specified PVC or Snapshot. If the provisioner does not support the specified data source, the volume will not be created and the failure will be reported as an event. In the future, we plan to support more data source types and the behavior of the provisioner may change." </ins> }, "resources": { "$ref": "#/definitions/io.k8s.api.core.v1.ResourceRequirements",

Discussion:
/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /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
Change:
switch { case err == nil: // Pod was created, feature supported. <del> StopPod(c, pod) </del> <ins> StopPodAndDependents(c, pod) </ins> return true, nil case apierrors.IsInvalid(err): // "Invalid" because it uses a feature that isn't supported.

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: I0722 06:26:18.056] I0722 06:26:18.057] [Driver: csi-hostpath] I0722 06:26:18.057] I0722 06:26:18.057] [Testpattern: Generic Ephemeral-volume (default fs) [Feature:GenericEphemeralVolume] (late-binding)] ephemeral skipped 448 lines unfoldmore I0722 06:30:33.845] Jul 22 06:30:33.845: INFO: Wait up to 5m0s for pod "inline-volume-tester2-hhcbd" to be fully deleted I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Pod inline-volume-tester-74jqh has the following logs: /dev/sda1 on /mnt/test-0 type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30) I0722 06:31:06.117] I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Deleting pod "inline-volume-tester-74jqh" in namespace "ephemeral-9141" I0722 06:31:06.155] Jul 22 06:31:06.155: INFO: Wait up to 5m0s for pod "inline-volume-tester-74jqh" to be fully deleted I0722 06:31:38.264] Jul 22 06:31:38.264: FAIL: no dangling PVCs I0722 06:31:38.264] Expected I0722 06:31:38.265] <[]v1.PersistentVolumeClaim | len:1, cap:1: [ I0722 06:31:38.265] { I0722 06:31:38.265] TypeMeta: {Kind: "", APIVersion: ""}, I0722 06:31:38.

265] ObjectMeta: { skipped 315 lines unfold_more I0722 06:32:16.896] STEP: Destroying namespace "ephemeral-9141" for this suite. I0722 06:32:16.931] Jul 22 06:32:16.931: INFO: Namespace ephemeral-9141 was already deleted I0722 06:32:16.932] STEP: Destroying namespace "ephemeral-522" for this suite. I0722 06:32:16.966] Jul 22 06:32:16.966: INFO: Namespace ephemeral-522 was already del Anything else we need to know: /cc /sig storage /priority critical-urgent /milestone v1.19
I have tracked this down and it looks like that changes were made in that affected how Pods were being deleted in the e2e framework (specifically commit ). This caused failures in other tests, so the commit was reverted in I will have a fix open shortly that uses foreground deletion only for these storage tests. /assign /cc Side note: I see already saw this
Change:
readonly KUBE_CLIENT_PLATFORMS elif [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then <del> KUBE_SERVER_PLATFORMS=(linux/amd64) </del> <ins> host_arch=$(kube::util::host_arch) if [[ "${host_arch}" != "amd64" && "${host_arch}" != "arm64" ]]; then # on any platform other than amd64 and arm64, we just default to amd64 host_arch="amd64" fi KUBE_SERVER_PLATFORMS=("linux/${host_arch}") </ins> readonly KUBE_SERVER_PLATFORMS <del> KUBE_NODE_PLATFORMS=(linux/amd64) </del> <ins> KUBE_NODE_PLATFORMS=("linux/${host_arch}") </ins> readonly KUBE_NODE_PLATFORMS if [[ "${KUBE_BUILDER_OS:-}" == "darwin"* ]]; then KUBE_TEST_PLATFORMS=( <del> darwin/amd64 linux/amd64 </del> <ins> "darwin/${host_arch}" "linux/${host_arch}" </ins> ) readonly KUBE_TEST_PLATFORMS KUBE_CLIENT_PLATFORMS=( <del> darwin/amd64 linux/amd64 </del> <ins> "darwin/${host_arch}" "linux/${host_arch}" </ins> ) readonly KUBE_CLIENT_PLATFORMS else <del> KUBE_TEST_PLATFORMS=(linux/amd64) </del> <ins> KUBE_TEST_PLATFORMS=("linux/${host_arch}") </ins> readonly KUBE_TEST_PLATFORMS <del> KUBE_CLIENT_PLATFORMS=(linux/amd64) </del> <ins> KUBE_CLIENT_PLATFORMS=("linux/${host_arch}") </ins> readonly KUBE_CLIENT_PLATFORMS fi else

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When trying to build kubectl from tip () on a M1 Macbook: Why is this needed: M1 MacBooks are a new major client platform that many developers will use. brew listed kubectl (kubernetes-cli) is one of the major packages still not supported on M1 () Since it's supported by go, it's only required to add it to the supported client list Locally I managed to add support using the following patch:
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 cli architecture
/sig release
Any updates on this? cheers
you can watch the PR:
it works, nice!!!
Done!!!
Change:
if _, err := fmt.Fprintf(w, "%st%vt%vt%vt%s", name, <del> "-", backendStringer(ingress.Spec.Backend), </del> <ins> formatHosts(ingress.Spec.Rules), </ins> loadBalancerStatusStringer(ingress.Status.LoadBalancer), <ins> formatPorts(ingress.Spec.TLS), </ins> translateTimestamp(ingress.CreationTimestamp), ); err != nil { return err

Discussion:
We should show a nicely formatted map, with tls and ports. This 50% works. Today we have: Which works well enough, but printing a single Ingress involves hand managing tabs and newlines till the entire Ingress is printed, i.e: So when we start mixing different Ingress types, we get jarring output: This is because the columns are formatted per the top ingress and don't match the bottom one. The tabbed writer used by kubectl to align columns gets confused on the whole.
you can assign this to me, will fix this next-candidate.
thanks!
Sounds like we should keep it to a single line () and move everything else to describe. Makes this bug easier.
yeah, we will move this to a single line, this is the principle.
was this finished for 1.3?
the code is already finished on my local branch. I will open a PR as I confirmed it.
what do you think if print ingress like this: Also the original resource is:
That would fall right off the screen. I think we have to stick to just printing the ips in , and everything else in . You can print hoststs alone, and optimize for small ingresses by doing something like we do for endpoints (show a small number of characters then do "..."). The problem with trying to print everything on one line is you can't represent the fanout cleanly, ie you might do: But with multiple hosts: Doesn't work, because /bar and secret2 only applies to
I agree with this, maybe we should just remove these rules from get ingress output or just leave host here.
SGTM are you going to send a pr?
yes, ready to.
Change:
JSONPatchMaxCopyBytes:       -10 * 1024 * 1024, MaxRequestBodyBytes:         10 * 1024 * 1024, }, <del> expectErr: "--json-patch-max-copy-bytes can not be negative value", </del> <ins> expectErr: "ServerRunOptions.JSONPatchMaxCopyBytes can not be negative value", </ins> }, { name: "Test when MaxRequestBodyBytes is negative value",

Discussion:
kube-apiserver has no --max-resource-write-bytes & --json-patch-max-copy-bytes option. Correct the error message to not use the "--max-resource-write-bytes" & "--json-patch-max-copy-bytes" string. Check the source code: No response v1.19 ~ v1.23 eg: </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery /area apiserver /kind cleanup /assign FYI:
/cc /triage accepted
Change:
} } <del> if !skipPreFlight { fmt.Println("Running pre-flight checks") err := preflight.RunInitMasterChecks(cfg) if err != nil { return nil, &preflight.PreFlightError{Msg: err.Error()} } } else { fmt.Println("Skipping pre-flight checks") } </del> // Auto-detect the IP if len(cfg.API.AdvertiseAddresses) == 0 { // TODO(phase1+) perhaps we could actually grab eth0 and eth1

Discussion:
Environment: VMware CentOS Linux release 7.2.1511 (Core) kernel: 3.10.0-327.36.1.el7.x8664 Installed packages: kubeadm.x8664 1.5.0-0.alpha.0.1534.gcf7301f kubectl.x8664 1.4.0-0 kubelet.x8664 1.4.0-0 kubernetes-cni.x8664 0.3.0.1-0. docker-engine.x8664 1.11.2- docker-engine- 1.12.1- What happened: kubeadm init hangs indefintely after: kubeadm init <master/tokensgenerated token: "." <master/pkicreated keys and certificates in "/etc/kubernetes/pki" <util/kubeconfigcreated "" <util/kubeconfigcreated "" <master/apiclientcreated API client configuration <master/apiclientcreated API client, waiting for the control plane to become readykubeadm init What you expected to happen: Master node initialize Anything else do we need to know: Only the kubeadm and kublet processes are running. When I do docker ps no containers are running. If i type docker images the only image that has been downloaded are: I've also tried: kubeadm init --api-advertise-addresses but with the same outcome (followed the clean-up at ) Im behind a firewall so I'm using proxy settings for docker. I have confirmed I can reach images on docker hub and google cloud registry
will download the required binaries viz etcd. When you are behind firewall kubeadm will hang/wait forever to download the binaries. I dont know whether it is addressed correctly in kubeadm implementation. I am also facing the same issue and waiting for the resolution.
Thx, I suspected it to be some firewall issue. Do you know if there's a way to add httpsproxy & httpproxy settings to kubeadm?
Kubeadm doesn't seem to pick proxy environment variables. I am looking at recompiling with proxy support may work. But I dont know how to do that. Waiting for updates about proxy
This issue same as Lets join there. The solution mentioned there may work.

You can try kubeadm with patch applied from PR : It works at least in my environment behind restrictive proxy.
thanks, I will look into it
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/runtime" </ins> genericapirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/registry/generic" genericregistrytest "k8s.io/apiserver/pkg/registry/generic/testing" "k8s.io/apiserver/pkg/registry/rest" etcdtesting "k8s.io/apiserver/pkg/storage/etcd/testing" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/registry/registrytest" )

Discussion:
What happened: I created a namespace with finalizer, and then tried to delete it: The namespace can be deleted, and the finalizer is removed by garbage collection controller: What you expected to happen: Since kubectl species , it is not an orphaning operation, the finalizer should be removed in namespace store. How to reproduce it (as minimally and precisely as possible): Same as what I observed: a namespace. finalizer. . Anything else we need to know?: Environment: Kubernetes version (use ): HEAD
/sig api-machinery
cc
Discussion on slack: