jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // +build !windows /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package validation import ( "k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig" ) // validateKubeletOSConfiguration validates os specific kubelet configuration and returns an error if it is invalid. func validateKubeletOSConfiguration(kc *kubeletconfig.KubeletConfiguration) error { return nil } </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?: What happened: Pods stuck in terminating state on Windows node after deleting it What you expected to happen: Pods get terminated and should disappear from kubectl How to reproduce it (as minimally and precisely as possible): Run a pod with windows container Delete it Pods are still terminating Anything else we need to know?: Could you pls help to resolve this issue. K8s pods stuck as Terminating after getting deleted on windows node with windows container(IIS). Docker ps -a not showing this container, so it is completely deleted, but in kubectl it is marked as Terminating. For networking we using OVN. kubectl logs: kubelet logs: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Hyper-V VMs OS (e.g. from /etc/os-release): Windows Node: Master Node: NAME="Ubuntu" VERSION="16.04.4 LTS (Xenial Xerus)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 16.04.4 LTS" VERSIONID="16.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" VERSIONCODENAME=xenial UBUNTUCODENAME=xenial Kernel (e.g. ): Linux esd-kbrnts-lnx-1 4.13.0-37-generic ~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: OVN 2.7 on windows OVN 2.7.2 on linux Others: Docker Version on Windows node: Server Version: 17.06.2-ee-6
/sig windows
It needs sometime for kubelet to remove the pod. Could you wait a while and check whether the Pod removed?
Hi actually I have waited for 1 day, and it is not deleting. Can delete it only using --grace-period=0 --force. But I don't want to use this manual approach). Could you pls give some advice on this? Thanks in advance!
is a reference to this issue. Checking kubelet logs will always help to troubleshoot such problem.
Code change:
<ins> // +build !windows /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package validation import ( "k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig" ) // validateKubeletOSConfiguration validates os specific kubelet configuration and returns an error if it is invalid. func validateKubeletOSConfiguration(kc *kubeletconfig.KubeletConfiguration) error { return nil } </ins>

Related discussion:
text: Actually, I have attached kubelet log in the ticket and think the main reason is Also as there any option for kubelet to automatically force delete Terminating pods after some period? And --containerized is also not solving my issue. Thanks!
Kubelet won't delete the pod from apiserver. Since it is already not exist on the node, you could force delete it by kubectl.
It is clear, so how we can resolve this error: ? I think this is the core item of our issue. Thanks.
I'm not using OVN. Have you met this problem when using OVN?
adding Bob to comment on this. i have seen this issue before, but it has been quite a while.
Hi, Guys will be very grateful if you will provide some solution for it. We have tried to add to deployment spec but it doesn't help. Thanks.
The error message of is actually a warning message. It shouldn't block the removal of pods. Could you recheck the following things: the node, check whether the pod is still existing, e.g. by the pod exists, check if there are other error or warning message in kubelet logs; or else, the pod could be force removed safely from apiserver
Hi, I had posted this info in the ticket description. not showing this container, so it is completely deleted, but in kubectl it is displayed as Terminating.
i think you may get more support and faster responses in our slack channel for sig-windows.
So it could be safely force removed from API. And agreed with slack is a more faster way to such troubleshooting issues.
The issue seems to be related to . The only platform specific implementation for PodContainerManager is the one for . There is a default implementation (), that always returns true in the Exists call. Disabling the CgroupsPerQOS option on the Windows nodes resolves the issue.
Windows doesn't support cgroups. You should always disable it.
it is clear enough that Windows does not support cgroups). Unfortunately, it's not specified in the documentation. So to disable CgroupsPerQOS you should need to add this flags to kubelet: Maybe it will help someone... Thank you all for discussion!
Code change:
sleep 2 done <ins> # Basic sanity checking for (( i=0; i<${#MINION_NAMES[@]}; i++)); do # Make sure docker is installed gcutil ssh ${MINION_NAMES[$i]} which docker > /dev/null if [ "$?" != "0" ]; then echo "Docker failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi # Make sure the kubelet is running gcutil ssh ${MINION_NAMES[$i]} /etc/init.d/kubelet status if [ "$?" != "0" ]; then echo "Kubelet failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi done </ins> echo echo "Kubernetes cluster is running.  Access the master at:" echo

Related discussion:
text: What happened: Deployment of node-local-dns in an ipv6-only cluster fails with the following iptables-related error Does node-local-dns support binding to IPv6 addresses? If not, can node-local-dns be used in an ipv6-only cluster? What you expected to happen: node-local-dns is up and running normally and binding to an ipv6 link-local address How to reproduce it (as minimally and precisely as possible): Create an ipv6-only cluster using nodes with single ipv6 stack Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 Cloud provider or hardware configuration: Openstack VMs OS (e.g: ): SLES 15 SP1 Kernel (e.g. ): 4.12.14-197.45-default Install tools: kubeadm Network plugin and version (if this is a network-related bug): calico v3.12.0 Others:
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
seems that node-local-dns only supports IPv4
looks like whatever's calling might need to have a log msg b4 it
/assign
Looks like there's already a logging statement for running iptables checks: Perhaps the log level was too low for that log message to get tripped?
hi Matt, ok so your looking at the logs? If you want you can into one of your kind nodes. Then edit run and if you wanna hack around in there, and open inside that container, which will allow you to play with the logging verbosity of Kubelet. If you decide its a good idea to surface this info then you can test there (). There are probably ways to plumb Kubelet args directly into kind also but that's just my off the cufff answer :)
/assign
/assign /assign
Not yet, node-local-dns is not supported to run on ipv6-only clusters.
/remove-triage unresolved
Thank you for letting me know, and thank you all for your efforts following through with the issue, I'll keep watch for any future updates on the feature.
I put together a patch to to make it more clear in this case what the issue is. Do you think it's worth moving forward with adding that log statement?
Code change:
sleep 2 done <ins> # Basic sanity checking for (( i=0; i<${#MINION_NAMES[@]}; i++)); do # Make sure docker is installed gcutil ssh ${MINION_NAMES[$i]} which docker > /dev/null if [ "$?" != "0" ]; then echo "Docker failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi # Make sure the kubelet is running gcutil ssh ${MINION_NAMES[$i]} /etc/init.d/kubelet status if [ "$?" != "0" ]; then echo "Kubelet failed to install on ${MINION_NAMES[$i]} your cluster is unlikely to work correctly" echo "Please run ./cluster/kube-down.sh and re-create the cluster. (sorry!)" exit 1 fi done </ins> echo echo "Kubernetes cluster is running.  Access the master at:" echo

Related discussion:
text: (I know I'd have to redo the patch differently, I did it a really dumb way and sure there's a much much better way :) ) Happy to do the leg work on this! Thanks for the guidance! Edit: forgot to mention, this is only supposed to be a stopgap short-term solution before node-local-dns gets support for IPv6!
so , is what pramesh is suggesting as simple as running something in to figure out if there is an ipv4 address... and if not, ... fail ?
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 /assign I have a PR ready, but we need to update the KEP, the docs and add some testing, ... targeting 1.21
Code change:
Phase: api.NamespaceActive, }, } <del> store := cache.NewStore(cache.IndexFuncToKeyFuncAdapter(cache.MetaNamespaceIndexFunc)) </del> <ins> reactFunc := func(action testclient.Action) (runtime.Object, error) { switch { case action.Matches("get", "namespaces"): if getAction, ok := action.(testclient.GetAction); ok && getAction.GetName() == namespaceObj.Name { return namespaceObj, nil } case action.Matches("list", "namespaces"): return &api.NamespaceList{Items: []api.Namespace{*namespaceObj}}, nil } return nil, fmt.Errorf("No result for action %v", action) } store := cache.NewStore(cache.MetaNamespaceKeyFunc) </ins> store.Add(namespaceObj) <del> mockClient := &testclient.Fake{} </del> <ins> fakeWatch := watch.NewFake() mockClient := &testclient.Fake{Watch: fakeWatch, ReactFn: reactFunc} </ins> lfhandler := NewLifecycle(mockClient).(*lifecycle) lfhandler.store = store handler := admission.NewChainHandler(lfhandler) pod := api.Pod{ <del> ObjectMeta: api.ObjectMeta{Name: "123", Namespace: namespaceObj.Namespace}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "123", Namespace: namespaceObj.Name}, Spec: api.PodSpec{ Volumes:    []api.Volume{{Name: "vol"}}, Containers: []api.Container{{Name: "ctr", Image: "image"}}, }, } badPod := api.Pod{ ObjectMeta: api.ObjectMeta{Name: "456", Namespace: "doesnotexist"}, </ins> Spec: api.PodSpec{ Volumes:    []api.Volume{{Name: "vol"}}, Containers: []api.Container{{Name: "ctr", Image: "image"}},

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
}, }, Capacity: v1.ResourceList{ <del> v1.ResourceCPU:     *resource.NewMilliQuantity(3000, resource.DecimalSI), v1.ResourceMemory:  *resource.NewQuantity(20E9, resource.BinarySI), v1.ResourceStorage: *resource.NewQuantity(500*mb, resource.BinarySI), v1.ResourcePods:    *resource.NewQuantity(0, resource.DecimalSI), </del> <ins> v1.ResourceCPU:    *resource.NewMilliQuantity(3000, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(20E9, resource.BinarySI), v1.ResourcePods:   *resource.NewQuantity(0, resource.DecimalSI), </ins> }, Allocatable: v1.ResourceList{ <del> v1.ResourceCPU:     *resource.NewMilliQuantity(2800, resource.DecimalSI), v1.ResourceMemory:  *resource.NewQuantity(19900E6, resource.BinarySI), v1.ResourceStorage: *resource.NewQuantity(500*mb, resource.BinarySI), v1.ResourcePods:    *resource.NewQuantity(0, resource.DecimalSI), </del> <ins> v1.ResourceCPU:    *resource.NewMilliQuantity(2800, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(19900E6, resource.BinarySI), v1.ResourcePods:   *resource.NewQuantity(0, resource.DecimalSI), </ins> }, }, }

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. 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
Code change:
}) ginkgo.It("should provide Internet connection for containers [Feature:Networking-IPv4]", func() { <del> ginkgo.By("Running container which tries to ping 8.8.8.8") </del> <ins> ginkgo.By("Running container which tries to connect to 8.8.8.8") </ins> framework.ExpectNoError( <del> framework.CheckConnectivityToHost(f, "", "ping-test", "8.8.8.8", framework.IPv4PingCommand, 30)) </del> <ins> framework.CheckConnectivityToHost(f, "", "connectivity-test", "8.8.8.8", 53, 30)) </ins> }) ginkgo.It("should provide Internet connection for containers [Feature:Networking-IPv6][Experimental]", func() { <del> ginkgo.By("Running container which tries to ping 2001:4860:4860::8888") </del> <ins> ginkgo.By("Running container which tries to connect to 2001:4860:4860::8888") </ins> framework.ExpectNoError( <del> framework.CheckConnectivityToHost(f, "", "ping-test", "2001:4860:4860::8888", framework.IPv6PingCommand, 30)) </del> <ins> framework.CheckConnectivityToHost(f, "", "connectivity-test", "2001:4860:4860::8888", 53, 30)) </ins> }) // First test because it has no dependencies on variables created later on.

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: Since when has it been failing: Ever Reason for failure: Vm on Azure with no public IP assigned aren't able to perform a command to the internet. Anything else we need to know: The test (see ) tries to test the internet connection for a pod by pinging 8.8.8.8. But azure does not provide ICMP support for VM without a public IP therefore this test cannot succeed.(see ) A fix would be to change the test method to a tcp request instead of a ping request (the test already performs a http get to in its BeforeSuite (see ))
/sig network /sig testing /sig azure
you may refer to (Pods don't have connectivity to external networks )
cc WDYT about the proposal to change this from an ICMP call? We probably need input from sig-architecture as well since this as well /sig architecture
/triage unresolved
An alternative is to issue a TCP/UDP request to 8.8.8.8 on port 53.
ICMP is dropped by Azure for security reasons. This is intended. Can use curl as a replacement. I will fix the corresponding test.
SGTM
Can you please review the related PR? I'll in the PR again. Thanks!
Code change:
<ins> // +build !windows /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package debugger import "syscall" // compareSignal is the signal to trigger cache compare. For non-windows // environment it's SIGUSR2. var compareSignal = syscall.SIGUSR2 </ins>

Related discussion:
text: PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: Currently, the feature is set up at the end of in . This setup should be moved into its own helper function, preferably in the package. /sig scheduling /kind cleanup /help
/assign /remove-help
I'd like to take this one
/remove-help
the PR I sent should resolve this one. :disappointed: Are any of the others still available?
Code change:
) func performContainerRuntimeUnitOp(op containerRuntimeUnitOp) error { <del> ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) </del> <ins> ctx, cancel := context.WithTimeout(context.Background(), 2*time.Minute) </ins> defer cancel() conn, err := dbus.NewWithContext(ctx)

Related discussion:
text: E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully Perma failure here: E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully E2eNode Suite.[It] [sig-node] MirrorPodWithGracePeriod when create a mirror pod and the container runtime is temporarily down during pod termination [NodeConformance] [Serial] [Disruptive] the mirror pod should terminate successfully Since it was created at No response No response /sig node
/cc
/cc /cc is there anything specific to CRI-O that will make test fail
/assign
The test fails there: Hm, scraping the kubelet logs it looks like that we miss a metric: cc
/triage accepted /priority important-soon seeing this in the wild
failed for this in as well
It seems to fail on on :
Having a fix in mind in
Code change:
# function kube::codegen::gen_client() { local in_pkg_root="" <ins> local one_input_api="" </ins> local out_pkg_root="" local out_base="" # gengo needs the output dir must be $out_base/$out_pkg_root local clientset_subdir="clientset"

Related discussion:
text: function in script has following issues: function only supports file but we have multiple types file with name as in . Hence this function is not working in our case. For the mitigation there is already an open . I have asked for including our changes as well. We have multiple files under a for example and . Because of this for appears twice and it generates duplicate informers We only need unique elements before passing it to . I followed this approach for unique elements: We have packages under . Earlier we were generating client only for and . But with the new I am not able to do that. I am using the following call to function: It results in following flags to As there is no directory as , it doesnot generate anything. Is it still possible to call on specific folder as it was done with earlier scripts? One mitigation I can think of is to call function on whole and then remove the marker from the types for which genclient is not needed. But the issue is we won't be able to pass the flag for each pkg. function in script is not working as expected.
/sig api-machinery
/cc
/triage accepted
Hi . I knew that there were all sorts of clients out there doing all sorts of things with these scripts, so I am not surprised to find you. :) Do you have a PR which attempts to use kube_codegen, so I can repro your issues directly?
I think you have one too many in there Aside from that, the real problem here is that these old codegen tools make some deeeeeeep assumptions about the ability to string-join various arguments and get the right results. It's awful. I was trying to make it simpler in this script, which I did for all of the in-tree consumers, but out of tree people apparently don't always follow the same conventions. For example, we generate clients for every directory that requests it. For a reason I do not know, you have files like which say but you don't actually want a client? If you specify then it t
So this code expects that you generate an omnibus client. What if I add a flag, like which you can use to call it for each API to make distinct clients? In truth the codegen tools need to be fixed, but that has SO MUCH ripple I just can't right now.
Code change:
# function kube::codegen::gen_client() { local in_pkg_root="" <ins> local one_input_api="" </ins> local out_pkg_root="" local out_base="" # gengo needs the output dir must be $out_base/$out_pkg_root local clientset_subdir="clientset"

Related discussion:
text: As the codegen was breaking us at several step, hence didn't prepared the PR.
Thanks for the PR. I have one more concern, is it possible to call and client-gen on the same pkg? With the current script, that is not possible because of the line It removes all the generated files first and then calls the . Hence the later clientset gen will remove the earlier generated clients.
Why are you generating a client for an internal version that isn't served?
My mistake. We need to stop using clients for internal versions.