jiebi/CodeConvo huggingface dataset:
Change:
cmd.Flags().BoolVar(&options.IgnoreDaemonsets, "ignore-daemonsets", false, "Ignore DaemonSet-managed pods.") cmd.Flags().BoolVar(&options.DeleteLocalData, "delete-local-data", false, "Continue even if there are pods using emptyDir (local data that will be deleted when the node is drained).") cmd.Flags().IntVar(&options.GracePeriodSeconds, "grace-period", -1, "Period of time in seconds given to each pod to terminate gracefully. If negative, the default value specified in the pod will be used.") <del> cmd.Flags().DurationVar(&options.Timeout, "timeout", 0, "The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object") </del> <ins> cmd.Flags().DurationVar(&options.Timeout, "timeout", 0, "The length of time to wait before giving up, zero means infinite") </ins> return cmd }

Discussion:
In writing some documentation for I noticed some issues with the implementation. I think the simplest user experience is that the command doesn't return until all the user pods are drained off the machine. In particular this means wait until all graceful termination is finished infinitely retry evictions that are rejected due to insufficient PodDisruptionBudget The current implementation does not do this, in particular wait for graceful termination appears to be at 10 sec number of pods, which may be much shorter than the max graceful termination we only retry evictions number of times My suggestion is to change the behavior so that we compute how long to wait for graceful termination, by taking max(grace periods of all pods that we want to delete) (or the value of --grace-period command line argument instead, if that is specified), and wait exactly that amount of time plus a small buffer we retry evictions infinitely WDYT? I think we should do this in 1.5 because the current behavior is very non-obvious.
The problem here is how long should we wait, if the user doesn't specify a timeout. The default timeout used in drain is following how long the reapers have in , , and . Maybe this is not long enough. I can make the changes. Do we still need exponential back off?
To summarize discussion with there are two possible approaches (pseudocode below) 1) Goroutine approach: For each pod P that meets the , do the following: 2) Non-goroutine approach: where "not timed out yet" means you haven't finished waiting max(--grace period argument to kubectl drain, max graceful termination spec across all pods on the node)
Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
The PR for this issue is waiting to be merged.
marking this as a release blocker due to being marked as such. Please update if needed cc:
Change:
// Check against i+1 so we exit if minTries == maxTries. if eps.Equal(expectedEps) && i+1 >= minTries { <del> framework.Logf("Found all expected endpoints: %+v", eps.List()) return </del> <ins> framework.Logf("Found all %d expected endpoints: %+v", eps.Len(), eps.List()) return nil </ins> } framework.Logf("Waiting for %+v endpoints (expected=%+v, actual=%+v)", expectedEps.Difference(eps).List(), expectedEps.List(), eps.List())

Discussion:
What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar
Change:
name: "pod logs", obj:  testPodWithOneContainers(), actions: []testclient.Action{ <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{ {

Discussion:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /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
Change:
}) framework.ExpectNoError(err, "failed to update namespace status %s", ns) gomega.Expect(statusUpdated.Status.Conditions).To(gomega.HaveLen(len(statusUpdated.Status.Conditions)), "updated object should have the applied condition, got %#v", statusUpdated.Status.Conditions) <del> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Type).To(gomega.Equal("StatusUpdate"), "updated object should have the approved condition, got %#v", statusUpdated.Status.Conditions) </del> <ins> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Type).To(gomega.Equal(v1.NamespaceConditionType("StatusUpdate")), "updated object should have the approved condition, got %#v", statusUpdated.Status.Conditions) </ins> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Message).To(gomega.Equal("Updated by an e2e test"), "The Message returned was %v", statusUpdated.Status.Conditions[0].Message) framework.Logf("Status.Condition: %#v", statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1]) })

Discussion:
[It] [sig-api-machinery] Namespaces [Serial] should apply changes to a namespace status [Conformance] Since Change on the assertions semantics? No response /sig api-machinery /sig testing
/assign This test is critical as it is in the conformance suite
/priority critical-urgent
FYI: The following tests are also failing: master informing master-blocking
It should be resolved by
/triage accepted
Change:
} return requests.Memory().Value() case v1.ResourceEphemeralStorage: <ins> // if the local storage capacity isolation feature gate is disabled, pods request 0 disk. if !utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) { return 0 } </ins> quantity, found := (*requests)[v1.ResourceEphemeralStorage] if !found { return 0

Discussion:
The scheduler does not properly calculate pod requests for a resource as - it ignores init containers completely in . This would allow a workload to get "free" scheduling above the limit of containers (mitigated by quota, which calculates this properly) and so the scheduler would make non-optimal fits. Both kubelet and scheduler enforce the , so you can't actually schedule, but you sometimes get steered to the wrong node if you have more init container resource usage than containers. in should use and the similar helpers instead of writing its own method to calculate the request for resources. /sig scheduling
/priority important-soon
Let me follow this issue. /assign
fyi
After I checked the implementation of function, I think we just need to use it to instead of the function in the scheduler.
/priority critical-urgent
Is the pod phase not considered? When the pod phase is running, the requested resource is actually considered as . This change seems to reduce the resource utilization of the node.
Actually, I don't think we need to consider the pod.Phase. The resource request & limit are mainly used in the scheduling process. The scenario you said is not belong to the responsibility of kube-scheduler
Correct. Setting appropriate requests/limits that maintain good node usage is users responsibility. Considering the max(initContainers, sum(containers)) is the documented behavior.
I understand. Thank you for your comments!
Change:
} gcClientset := ctx.ClientBuilder.ClientOrDie("generic-garbage-collector") <ins> discoveryClient := ctx.ClientBuilder.DiscoveryClientOrDie("generic-garbage-collector") </ins> config := ctx.ClientBuilder.ConfigOrDie("generic-garbage-collector") metadataClient, err := metadata.NewForConfig(config)

Discussion:
Ran kube-controller-manager with and observed this in the log every 30 seconds: This is also happening in 1.20, 1.19, and 1.18 The GC and quota clients look up discovery information every 30 seconds. They have a QPS of 20 requests per second and a burst of 30 requests. Default configuration of kube-controller-manager runs without constant throttling warnings. /sig api-machinery
/assign /triage accepted
Change:
} vmID, err := pc.InstanceID(nodeName) <ins> if err == cloudprovider.InstanceNotFound { glog.Infof("Instance %q does not exist, disk %s will be detached automatically.", nodeName, pdID) return false, nil } </ins> if err != nil { glog.Errorf("Photon Cloud Provider: pc.InstanceID failed for DiskIsAttached. Error[%v]", err) return false, err

Discussion:
Cloud provider volume has a function DiskIsAttached to check whether the volume is still attached to the instance. If the instance is no longer exist (deleted by cloud provider), we can safely assume that the volume is no longer attached to the instance and return false without error for DiskIsAttached(). Currently GCE PD and AWS has the correct behavior, but all other volume plugins do not.
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
In order to be easier to review, I split it for every cloud provider.
cinder plugin (openstack, rackspace):
Anyone can merge this PR:?
Change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ <ins> JumpChain: "RETURN", SourceAddress: "127.0.0.0/8", }, { </ins> JumpChain: string(kubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { JumpChain: string(kubeNodePortChain), MatchSet: "",

Discussion:
Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted
Change:
} } __EOF__ <del> fi </del> } kube::log::status "Running kubectl tests for kube-apiserver"

Discussion:
I am running locally which is failing with the following error: Is this expected? Is there a way to change that path? cc
starts kubelet as a normal user, which doesn't have the permission to create the socket in . I think we can create a new kubelet flag to pass this path. /cc
From test- at "# This command checks that the built commands can function together for simple scenarios. It does not require Docker." In this case, can we update this not require On another hand, why test-cmd requires a working Kubelet which does nothing today?
Yes kubectl tests should not really require kubelet. I think it should be fine to remove it if the tests pass without it. cc who own this I think.
See . It passed locally for me.
Change:
ExtraEndpointPorts:        c.ExtraConfig.ExtraEndpointPorts, PublicServicePort:         publicServicePort, KubernetesServiceNodePort: c.ExtraConfig.KubernetesServiceNodePort, <del> } </del> <ins> }, nil </ins> } // PostStartHook initiates the core controller loops that must exist for bootstrapping.

Discussion:
Clusters created with kubeadm using DualStack are not able to work, because CoreDNS pods never get ready Seeing one failed job logs It seems that the pod is "waiting for the kubernetes service"?? coredns version seems the same as in the working jobs CoreDNS pod should be ready Instal a Dual-stack cluster using master with kubeadm (or kind ) ! It started to fail on Oct12 <details</details<details</details<details</details<details</details<details</details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
/cc I didn't notice it was failing for more than 1 month :facewithhead_bandage: I didn't have time to dig into it yet, but this PR landed just that day how is that the pods running has the version 1.8.4 but the PR seems to update kubeadm to 1.8.6?
Looking into this today. The error from CoreDNS should only happen when the kubernetes plugin fails to sync with the Kubernetes API, either because it can’t connect, or it can’t sync the lists of services/endpointslices. There were changes and fixes to the API connection code, so it could be a regression.
Actually no. The changes I was thinking of were already in 1.8.4.
How can we reproduce it : Instal a Dual-stack cluster using master with kubeadm (or kind ) I was unable to reproduce this issue in a kind dual stack cluster.

After upgrading coredns to 1.8.6 (from 1.8.0 installed by kind), and adding list/watch permission for endpointslice, the pods were ready. edit: It also works for coredns 1.8.4 - I'm unclear as to which version I should be checking.
let me check if is a regression in kind :thinking:
working with 1.8.6 and yesterdays kubernetes podIPs
This is weird, I hit a similar issue in openshift, endpoints doesn't match the IP family of the kubernetes.default service apiserver service is single stack, at least until this KEP fixes it What I don't understand is why the order of the IPs in kind is different let me try to fix both things /assign
my fault, sorry for the noise :sweat_smile:
Change:
// Suddenly, a wild scheduler appears: _, err = bindingRegistry.Create(ctx, &api.Binding{ <del> ObjectMeta: api.ObjectMeta{Namespace: api.NamespaceDefault, Name: "foo"}, Target:     api.ObjectReference{Name: "machine"}, </del> <ins> ObjectMeta: api.ObjectMeta{ Namespace:   api.NamespaceDefault, Name:        "foo", Annotations: map[string]string{"label1": "value1"}, }, Target: api.ObjectReference{Name: "machine"}, </ins> }) if err != nil { t.Fatalf("unexpected error: %v", err)

Discussion:
Recap of related tangent in follows. Use case: I need to implement mesos task reconciliation in the kubernetes-mesos scheduler. If it crashes and then restarts, I want to be able to recover things like taskID, slaveID, offerID, etc. so as to rebuild the internal state of the scheduler. Once state is recovered, I can reconcile the against the tasks that the mesos master knows about. If I can't use binding annotations for this, then I need to store state some other (super inconvenient) way. Currently the etcd registry assignPod() implementation drops binding annotations on the floor. It should not, and instead they should be preserved for later access. Proposal: Store binding-related annotations in a new field: Pod.Status.Annotations When setting Pod.Status.Host="{some-host-name}" via assignPod(), binding annotations are copied in from Binding When cloning Pod.Status.Host in UpdatePod() (for an already-scheduled pod), the Pod.Status.Annotations are also cloned. I don't think /bindings has to be a readable apiserver endpoint, as long as the binding metadata is exposed some other way, as proposed above. I'd also like to propose that once binding annotations are "bound" to Pod.Status they become read-only. So they're essentially write-once, just like Pod.Status.Host is meant to be. cc xref
There is one situation where we probably want to clear Host, actually: in the case that the pod can't actually be materialized on the selected node for some reason, such as .
Any objection to a PR implementing my proposal? I'm happy to do the work.
You'll probably want to do it on top of (or after it lands) since that code path is changing significantly.
Though it is also represented in PodStatus, Host is properly a field in the PodSpec. Status must be completely reconstructable based on observations. The proposed Pod.Status.Annotations would not be. Furthermore, I don't think we should introduce another annotations field to Pod. I'd prefer to add a podAnnotations field to Binding, and then merge them into the pod. As for clearing the annotations, I'd prefer to simply fail a pod that was rejected by a node so as not to have to deal with that. Also note the discussion here re. moving binding to a pod subresource:
See also .
Change:
func TestGetEtcd(t *testing.T) { fakeClient := tools.MakeFakeEtcdClient(t) ch := make(chan interface{}, 1) <ins> manifest := api.ContainerManifest{ID: "foo", Version: "v1beta1", Containers: []api.Container{{Name: "1", Image: "foo"}}} </ins> fakeClient.Data["/registry/hosts/machine/kubelet"] = tools.EtcdResponseWithError{ R: &etcd.Response{ Node: &etcd.Node{ Value: api.EncodeOrDie(&api.ContainerManifestList{ <del> Items: []api.ContainerManifest{{ID: "foo"}}, </del> <ins> Items: []api.ContainerManifest{manifest}, </ins> }), ModifiedIndex: 1, },

Discussion:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.