jiebi/CodeConvo huggingface dataset:
Code change:
const ( pvDeletionTimeout       = 3 * time.Minute statefulSetReadyTimeout = 3 * time.Minute <ins> taintKeyPrefix          = "zoneTaint_" </ins> ) var _ = utils.SIGDescribe("Regional PD", func() {

Related discussion:
text: <!-- 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?: What happened: Testgrid: https://k8s-
/assign
The test's assumption about test parameter is wrong. Previously it assumed the group name is the same across all zones, but they are different in regional clusters. Looking into using node taints as the permanent fix, as suggested by the TODO comment in the test.
Hm I think taint based evictions is still an alpha feature.
OK. I propose the following solution: Get the zone of Schedule the StatefulSet pod to that zone using node affinity; wait for the pod to run Remove the node affinity from StatefulSet Delete
Can it be simplified? Schedule the pod Figure out which zone that pod got scheduled in Delete the instance group of that zone
Unfortunately I don't know of a good way to look up the instance group given the zone, since there could be instance groups from multiple clusters in the same project
How about: Schedule the pod Figure out the zone Taint all the nodes in the zone Kill the pod
Taint with NoSchedule? yeah that sounds good
Code change:
return multiGroupVersioner{target: gv, acceptedGroupKinds: groupKinds} } <ins> // NewCoercingMultiGroupVersioner returns the provided group version for any incoming kind. // Incoming kinds that match the provided groupKinds are preferred. // Kind may be empty in the provided group kind, in which case any kind will match. // Examples: //   gv=mygroup/__internal, groupKinds=mygroup/Foo, anothergroup/Bar //   KindForGroupVersionKinds(yetanother/v1/Baz, anothergroup/v1/Bar) -> mygroup/__internal/Bar (matched preferred group/kind) // //   gv=mygroup/__internal, groupKinds=mygroup, anothergroup //   KindForGroupVersionKinds(yetanother/v1/Baz, anothergroup/v1/Bar) -> mygroup/__internal/Bar (matched preferred group) // //   gv=mygroup/__internal, groupKinds=mygroup, anothergroup //   KindForGroupVersionKinds(yetanother/v1/Baz, yetanother/v1/Bar) -> mygroup/__internal/Baz (no preferred group/kind match, uses first kind in list) func NewCoercingMultiGroupVersioner(gv schema.GroupVersion, groupKinds ...schema.GroupKind) GroupVersioner { return multiGroupVersioner{target: gv, acceptedGroupKinds: groupKinds, coerce: true} } </ins> // KindForGroupVersionKinds returns the target group version if any kind matches any of the original group kinds. It will // use the originating kind where possible. func (v multiGroupVersioner) KindForGroupVersionKinds(kinds []schema.GroupVersionKind) (schema.GroupVersionKind, bool) {

Related discussion:
text: What happened: Set up a HA cluster with 1.9 and 1.10 API servers (occurs on any apiserver skew boundary where a cohabitating resource's storage version changed groups) Observed errors when modifying workload objects: when modified via the 1.10 server, saw this error in the 1.9 server: when modified via the 1.9 server, saw this error in the 1.10 server: When this error was encountered, all watchers for the resource in question would be dropped and have to re-establish, and the internal watchers feeding the watch cache would drop and re-establish What you expected to happen: Watch events from all supported storage versions are processed correctly How to reproduce it (as minimally and precisely as possible): Start a server from master (for inspectability, store in json). With Create a deployment (e.g. kube-dns in kube-system) Establish a watch via extensions (kubectl get deployments.extensions --all-namespaces -w) Establish a watch via apps (kubectl get --all-namespaces -w) Tail the kube-apiserver log Change the apps/v1 deployment in etcd to extensions/v1beta1: Observer client watches drop and server log errors: 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 api-machinery /cc /priority critical-urgent
error is triggered by this returning false: constructed here: the info about expected cohabitating groups is not included in the list of acceptable inputs
Code change:
import ( "fmt" <del> "strings" </del> "time" "k8s.io/kubernetes/pkg/api" <del> client "k8s.io/kubernetes/pkg/client/unversioned" </del> "k8s.io/kubernetes/pkg/util" . "github.com/onsi/ginkgo"

Related discussion:
text: We are running heapster, dns server, kube-proxy etc. in kube-system namespace. Some e2e tests try to make sure all those kube-system pods are at ready state before firing the real tests, others just simply ingore them. But both cases might cause e2e flakiness when some of those kube-system containers are in crashloop, for example, for heapster crashloop, for influxdb crashloop, etc. When such cases happen, the developer doesn't have much information on why since the nodes might be teared down. We should watch those kube-system pods, and onContainerFailure, we should collect the related logs. One simple way is using kubectl logs <Pod<Container--previous cc/
is this related enough to and that you can bundle it in?
The logs from the pods should be retrieved via the api server. This is different from the kubelet logs. I'll upload a PR for this.
Great job It will be very helpful for debugging.
Code change:
Name: "mypsp", }, Spec: policy.PodSecurityPolicySpec{ <ins> AllowedUnsafeSysctls: []string{"kernel.*", "net.ipv4.ip_local_port_range"}, ForbiddenSysctls:     []string{"net.ipv4.ip_default_ttl"}, </ins> SELinux: policy.SELinuxStrategyOptions{ Rule: policy.SELinuxStrategyRunAsAny, },

Related discussion:
text: /kind bug What happened: does not show the description for the new field in What you expected to happen: should describe the new field. How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version (use ): master
/sig auth
GitHub didn't allow me to assign the following users: fanzhangio. Note that only and repo collaborators 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
If nobody has started yet, I wanna to pick it up.
was working on it AFAIR.
Indeed. if you don't mind, I'd take over.
Code change:
defer testKubelet.Cleanup() kubelet := testKubelet.kubelet pods := newTestPods(5) <ins> now := metav1.NewTime(time.Now()) </ins> pods[0].Status.Phase = v1.PodFailed pods[1].Status.Phase = v1.PodSucceeded <ins> // The pod is terminating, should not filter out. </ins> pods[2].Status.Phase = v1.PodRunning <ins> pods[2].DeletionTimestamp = &now pods[2].Status.ContainerStatuses = []v1.ContainerStatus{ {State: v1.ContainerState{ Running: &v1.ContainerStateRunning{ StartedAt: now, }, }}, } </ins> pods[3].Status.Phase = v1.PodPending <ins> pods[4].Status.Phase = v1.PodRunning </ins> expected := []*v1.Pod{pods[2], pods[3], pods[4]} kubelet.podManager.SetPods(pods)

Related discussion:
text: pointed out that for scheduling and kubelet admission, we should consider resources of terminated-but-not-yet-deleted pods to still be in use, because it may take an arbitrary amount of time for the system to deallocate resources. We didn't check to see if this is currently how it is implemented or not. cc/ /sig scheduling
cc/
For terminated-but-not-yet-deleted & phase is case, the Pod is still in scheduler's cache, so it's handled well in scheduler; the Pod will be removed from cache when it's deleted. But in kubelet, it filtered terminated-but-not-yet-deleted out () when using scheduler.predicates. The option in my mind is to ~pass all Pods (including terminated-but-not-yet-deleted) to each admin, and let each admin decide whether filter terminated-but-not-yet-deleted out~ only filter out finished (Failed or Succeed) pods for Admits.
In -, it already consider by . So both scheduler & kubelet handles terminated-but-not-yet-deleted pods well.
Great, thanks for looking into it!
should this issue be closed then?
I think so.
Just to clarify: Kubelet correctly accounts the resources used by terminated-but-not-yet-deleted pods, i.e, kubelet does not count the resource usage of those pods towards total usage on the node. Scheduler, however, does not do the same. Scheduler waits for a pod to be deleted, and then it deducts its resource request from the associated node total usage. Upon deletion of a pod, scheduler is notified and acts: So, scheduler and kubelet behaviors are not exactly the same. I am not sure if scheduler can receive an event when a pod's container status changes. If it could, we could make the logic the same as that of Kubelet.
I guess the current behavior is OK because it is conservative (scheduler considers the resources to be in use even though kubelet considers them free). And actually it seems that scheduler is more "correct" than kubelet, since the resources really aren't usable until the pod is deleted, right? (IIUC that was Vish's original point)
I agree. The current behavior is correct, but a bit conservative. Basically, the scheduler side is more conservative and waits until a pod is deleted from the cache before considering its resources released.
Code change:
defer testKubelet.Cleanup() kubelet := testKubelet.kubelet pods := newTestPods(5) <ins> now := metav1.NewTime(time.Now()) </ins> pods[0].Status.Phase = v1.PodFailed pods[1].Status.Phase = v1.PodSucceeded <ins> // The pod is terminating, should not filter out. </ins> pods[2].Status.Phase = v1.PodRunning <ins> pods[2].DeletionTimestamp = &now pods[2].Status.ContainerStatuses = []v1.ContainerStatus{ {State: v1.ContainerState{ Running: &v1.ContainerStateRunning{ StartedAt: now, }, }}, } </ins> pods[3].Status.Phase = v1.PodPending <ins> pods[4].Status.Phase = v1.PodRunning </ins> expected := []*v1.Pod{pods[2], pods[3], pods[4]} kubelet.podManager.SetPods(pods)

Related discussion:
text: That said, I believe resources of terminated-but-not-deleted pods are usable on nodes (should be verified). So, the current behavior is a bit less than ideal in terms of efficiency, but AFAIK the duration between termination and deletion is only a few seconds. So, it may not be worth optimizing.
I thought was saying the opposite (see my first entry in this issue). Maybe he can clarify.
Code change:
podClient = f.PodClient() }) <del> ginkgo.Context("when creating a pod in the host PID namespace", func() { makeHostPidPod := func(podName, image string, command []string, hostPID bool) *v1.Pod { return &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: podName, }, Spec: v1.PodSpec{ RestartPolicy: v1.RestartPolicyNever, HostPID:       hostPID, Containers: []v1.Container{ { Image:   image, Name:    podName, Command: command, }, }, }, } } createAndWaitHostPidPod := func(podName string, hostPID bool) { podClient.Create(makeHostPidPod(podName, framework.BusyBoxImage, []string{"sh", "-c", "pidof nginx || true"}, hostPID, )) podClient.WaitForSuccess(podName, framework.PodStartTimeout) } nginxPid := "" ginkgo.BeforeEach(func() { nginxPodName := "nginx-hostpid-" + string(uuid.NewUUID()) podClient.CreateSync(makeHostPidPod(nginxPodName, imageutils.GetE2EImage(imageutils.Nginx), nil, true, )) output := f.ExecShellInContainer(nginxPodName, nginxPodName, "cat /var/run/nginx.pid") nginxPid = strings.TrimSpace(output) }) ginkgo.It("should show its pid in the host PID namespace [LinuxOnly] [NodeFeature:HostAccess]", func() { busyboxPodName := "busybox-hostpid-" + string(uuid.NewUUID()) createAndWaitHostPidPod(busyboxPodName, true) logs, err := e2epod.GetPodLogs(f.ClientSet, f.Namespace.Name, busyboxPodName, busyboxPodName) if err != nil { framework.Failf("GetPodLogs for pod %q failed: %v", busyboxPodName, err) } pids := strings.TrimSpace(logs) framework.Logf("Got nginx's pid %q from pod %q", pids, busyboxPodName) if pids == "" { framework.Failf("nginx's pid should be seen by hostpid containers") } pidSets := sets.NewString(strings.Split(pids, " ")...) if !pidSets.Has(nginxPid) { framework.Failf("nginx's pid should be seen by hostpid containers") } }) ginkgo.It("should not show its pid in the non-hostpid containers [LinuxOnly] [NodeFeature:HostAccess]", func() { busyboxPodName := "busybox-non-hostpid-" + string(uuid.NewUUID()) createAndWaitHostPidPod(busyboxPodName, false) logs, err := e2epod.GetPodLogs(f.ClientSet, f.Namespace.Name, busyboxPodName, busyboxPodName) if err != nil { framework.Failf("GetPodLogs for pod %q failed: %v", busyboxPodName, err) } pids := strings.TrimSpace(logs) framework.Logf("Got nginx's pid %q from pod %q", pids, busyboxPodName) pidSets := sets.NewString(strings.Split(pids, " ")...) if pidSets.Has(nginxPid) { framework.Failf("nginx's pid should not be seen by non-hostpid containers") } }) }) </del> ginkgo.Context("When creating a container with runAsUser", func() { makeUserPod := func(podName, image string, command []string, userid int64) *v1.Pod { return &v1.Pod{

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: , Which test(s) are failing: Since when has it been failing: since this PR introduced them Testgrid link: Note that this is the flakiest test in both dashboards, and failing quite frequently. Reason for failure: unknown Anything else we need to know: cc
/sig node
see: , both getting empty PID and multiple PIDs.
opened revert at
for discoverability for the release team /priority critical-urgent /milestone v1.17
Code change:
return err } <ins> // ignoreStatusForbiddenFromError returns nil if the status code is StatusForbidden. // This happens when AuthorizationFailed is reported from Azure API. func ignoreStatusForbiddenFromError(err error) error { if err == nil { return nil } v, ok := err.(autorest.DetailedError) if ok && v.StatusCode == http.StatusForbidden { return nil } return err } </ins> /// getVirtualMachine calls 'VirtualMachinesClient.Get' with a timed cache /// The service side has throttling control that delays responses if there're multiple requests onto certain vm /// resource request in short period.

Related discussion:
text: <!-- 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: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Code change:
new.Spec.RequiresRepublish = &requiresRepublish }, }, <ins> { name: "StorageCapacity changed", modify: func(new *storage.CSIDriver) { new.Spec.StorageCapacity = &notStorageCapacity }, }, </ins> } for _, test := range successCases { t.Run(test.name, func(t *testing.T) {

Related discussion:
text: Up to 1.21, that field is immutable. That means in practice, a CSIDriver object has to be deleted and then re-created with a different value instead. Mutation via delete/created is unnecessarily complex and as the only consumer of that field (the kube-scheduler) can handle mutation just fine (it'll always ask the informer cache for the current value), it's better to allow mutation.
/sig storage /assign
This is independent of allowing other fields to become mutable, but that might also make sense.
/triage accepted
Code change:
if in.XEmbeddedResource { out.VendorExtensible.AddExtension("x-kubernetes-embedded-resource", true) } <del> if in.XIntOrString { out.VendorExtensible.AddExtension("x-kubernetes-int-or-string", true) } </del> return nil }

Related discussion:
text: The server-side validation does not check the type of values with . Create a CRD like: Then create a CR: It is not rejected, but should because must not be a boolean.
Code change:
started = !exists } podStatus.ContainerStatuses[i].Started = &started <ins> if started { var ready bool if c.State.Running == nil { ready = false } else if result, ok := m.readinessManager.Get(kubecontainer.ParseContainerID(c.ContainerID)); ok { ready = result == results.Success } else { // The check whether there is a probe which hasn't run yet. _, exists := m.getWorker(podUID, c.Name, readiness) ready = !exists } podStatus.ContainerStatuses[i].Ready = ready } </ins> } // init containers are ready if they have exited with success or if a readiness probe has // succeeded.

Related discussion:
text: If I have probe and then all good. Previous version of the pod is terminated after startup probe success, but if wasn't specified the pod becomes ready immediately. It would be nice to add new state (for example starting) which would have pods until a is successful. Also, it would mean that container not ready for connection. Thank you for attention!
/sig cluster-lifecycle
/remove-sig cluster-lifecycle /sig apps try asking in #kubernetes-users on k8s slack.
they are silent in the chat. Who is involved in the development of startup probe?
i think this topic better fits SIG Node. try asking in their channel on slack , but be patient ;) /sig node /remove-sig apps
Those labels are not set on the issue: <detailsIn response to : i think this topic better fits SIG Node. /sig node /remove-sig apps </details
I think this is a feature request, not support, so I changed labels. On its face it SEEMS reasonable, but I am not close enough to the details to say. This is definitely sig-node.
Adding a new pod lifecycle state has been determined to be intractable in the past. Is the proposed change keeping the pod in !Ready until the first success from ?
Where do you usually discuss this? Just wondering. Yes, I want that pod considered not ready until will not be successful. If readiness probe doesn't present then a pod can become ready. How can a pod be ready if it is not running?
how long wait?
Looking at this issue, I can confirm it, at least superficially - a pod with a perma-failing is "ready" if there is no readinessGate defined and "not ready" if it is defined. The question I have is whether we think that is "correct" or not? Initially I thought it was correct, but the more I think about it the less convinced I am. If I have defined a startupProbe and it is not passing, my app should not be ready. Does anyone disagree?
Also, the app should not be ready in status. It's funny, but without a readiness probe, pods in the final state have the status ready and accept requests. This is unexpected.
Whether a pod is ready while terminating is an entirely different question, IMO.
Code change:
started = !exists } podStatus.ContainerStatuses[i].Started = &started <ins> if started { var ready bool if c.State.Running == nil { ready = false } else if result, ok := m.readinessManager.Get(kubecontainer.ParseContainerID(c.ContainerID)); ok { ready = result == results.Success } else { // The check whether there is a probe which hasn't run yet. _, exists := m.getWorker(podUID, c.Name, readiness) ready = !exists } podStatus.ContainerStatuses[i].Ready = ready } </ins> } // init containers are ready if they have exited with success or if a readiness probe has // succeeded.

Related discussion:
text: Apps that server network traffic probably need to "drain" and to do that they need to stay "ready" for a while as upstream LBs de-program. Let's not conflate issues, please.
The fix seems simple - lets see what CI says.
Sorry, I don't spend much time on slack... you could have checked the release notes in 1.18 ;-) Tim's fix seems good, thanks!
/reopen Until we merge all related PRs...
Reopened this issue. <detailsIn response to : /reopen Until we merge all related PRs... 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
All merged. /close
Closing this issue. <detailsIn response to : All merged. /close 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
Code change:
%.png: %.seqdiag $(FONT) seqdiag --no-transparency -a -f '$(FONT)' $< <ins> # Build the stuff via a docker image .PHONY: docker docker: docker build -t clustering-seqdiag . docker run --rm clustering-seqdiag | tar xvf - docker-clean: docker rmi clustering-seqdiag || true docker images -q --filter "dangling=true" | xargs docker rmi fix-clock-skew: boot2docker ssh sudo date -u -D "%Y%m%d%H%M.%S" --set "$(shell date -u +%Y%m%d%H%M.%S)" </ins>

Related discussion:
text: <!-- 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 /priority failing-test /area test-infra What happened: job is failing. See https://k8s- https://k8s- https://k8s- https://k8s- What you expected to happen: test should pass
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/assign
Reiterating the mentions to trigger a notification: <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
I'm guessing that something got messed up in the bazel cache when reverting from 0.5.2 to 0.4.5. I'm not sure how best to fix.
How about updating everything to bazel 0.5.3 at once? I know you're trying to do a step-by-step approach to avoid breakages, but I suspect it will be cheaper to just deal with a brief outage while we update? (aka update the bazelbuild image to 0.5.3 and then merge your PR with updated and working BUILD rules?)
there's at least one other issue I've discovered with the latest go rules - the binary no longer works, due to changes introduced in that might be arguably better (at least everything still builds?), though it's frustrating that it makes things more broken in a different way.
Code change:
"log" "os" "os/exec" <ins> "os/signal" </ins> "path/filepath" "strings" "time"

Related discussion:
text: Once e2e tests are running, the tests keep running even if I press and exit the process that controls the TTY. But the tests actually keep running in the background and they keep printing stuff on a shell prompt which has already returned and thereby clobbering the STDOUT
/assign
GitHub didn't allow me to assign the following users: oomichi. 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