I would recommend filing a Github issue about this. Discussing on the mailing list is not good for tracking this long-term.
On Mon, Jan 23, 2017 at 10:30 AM, Ben Kochie <sup...@gmail.com> wrote: > This sounds like a job that should happen at provisioning time, or by > config management software. > > On Jan 23, 2017 10:00, "Mayank" <krmaya...@gmail.com> wrote: > >> Yeah, my use case is basically change the permissions of the hostPath so >> that my pods running as non root can access it. I dont want a pod running >> as daemon set for this purpose, since the pod will just be sitting there >> doing nothing, until a new host appears or a host is reimaged, etc. I >> believe there is no way to mount a hostPath with so that a non root user >> can access. I would prefer to run a job externally once in a while to >> ensure this once in a lifetime needed thing. >> >> There have been other debugging use cases which , want you to run some >> commands on a subset of nodes and get their output and complete. I believe >> a first class kubernetes way of accomplishing those would be awesome, >> although most of those use cases are debugging scenarios. I do agree with >> the general sentiment that leaving a node dirty is a bad idea but debugging >> /testing scenarios or collecting some data by running some commands might >> be scenarios to consider. What do you all think ? >> >> -Mayank >> >> >> >> On Friday, January 20, 2017 at 4:46:25 PM UTC-8, Rodrigo Campos wrote: >>> >>> I also think having"state changes" it's a bad use case, as it's been >>> pointed out (it can be changed again, etc. No "self healing" once you have >>> state like that, that goes against most of the basic ideas of >>> reconciliation loops in k8s). >>> >>> But I want to add that, although that use case seems like a wrong idea, >>> there might be other valid use cases (like gather some data from nodes >>> once). Maybe it's a good idea to find them first :-) >>> >>> On Friday, January 20, 2017, Brandon Philips <brandon...@coreos.com> >>> wrote: >>> >>>> On Fri, Jan 20, 2017 at 1:40 PM 'Tim Hockin' via Kubernetes user >>>> discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >>>> >>>>> Concretely the "tweak a sysctl" thing leaves machines that are >>>>> "dirty". Once you allow any users to do this, the machines become >>>>> less useful for anyone else who doesn't specifically tolerate that >>>>> tweak. Almost every sysctl represents a tradeoff. Optimize for >>>>> low-latency network? Pay higher CPU and memory costs. And so on. >>>>> >>>> >>>> I am not saying it is necessarily the right solution for users; just >>>> that I have seen people wanting to do `kubectl get nodes | while read host >>>> ; ssh $host echo foo > /proc/sys/bar`. It would be nice to at least bring >>>> that into the API fold and auditing. >>>> >>>> Brandon >>>> >>>> >>>>> On Fri, Jan 20, 2017 at 12:33 PM, 'David Oppenheimer' via Kubernetes >>>>> user discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >>>>> > Brandon, would you like to file an issue in kubernetes/kubernetes to >>>>> start? >>>>> > FWIW the privileged run-to-completion node configuration script is a >>>>> use >>>>> > case we have also seen at Google, but the semantics get a bit >>>>> tricky. We >>>>> > could start with just a run-to-completion DaemonSet which I think >>>>> covers the >>>>> > use cases you mentioned as well as the one from Mayank. >>>>> > >>>>> > >>>>> > >>>>> > On Fri, Jan 20, 2017 at 10:26 AM, Brandon Philips >>>>> > <brandon.phil...@coreos.com> wrote: >>>>> >> >>>>> >> I think this would be a nice thing to have. I have seen a few users >>>>> >> wanting to do things like run a quick script against all nodes in a >>>>> cluster >>>>> >> that say tweaks a sysctl across the entire fleet. Or, gathers up >>>>> some >>>>> >> setting and pushes the results to some service. >>>>> >> >>>>> >> I think it would be worthwhile to gather other use cases and write a >>>>> >> proposal. >>>>> >> >>>>> >> On Fri, Jan 20, 2017 at 1:01 AM 'David Oppenheimer' via Kubernetes >>>>> user >>>>> >> discussion and Q&A <kubernetes-users@googlegroups.com> wrote: >>>>> >>> >>>>> >>> Unfortunately I don't think it's possible. The documentation for >>>>> >>> DaemonSet says the RestartPolicy must be Always. If it allowed >>>>> Never then it >>>>> >>> would do what you want. >>>>> >>> >>>>> >>> >>>>> >>> On Thu, Jan 19, 2017 at 2:37 PM, Mayank <krmaya...@gmail.com> >>>>> wrote: >>>>> >>>> >>>>> >>>> Hi All >>>>> >>>> Is there a way to create a kubernetes job that runs on all nodes >>>>> in the >>>>> >>>> cluster and then finishes without creating one job per node using >>>>> node >>>>> >>>> selector ? Or may be this is enhancement to say run this job on >>>>> all hosts >>>>> >>>> with regex *.ops.net and viola >>>>> >>>> >>>>> >>>> -Mayank >>>>> >>>> >>>>> >>>> -- >>>>> >>>> You received this message because you are subscribed to the Google >>>>> >>>> Groups "Kubernetes user discussion and Q&A" group. >>>>> >>>> To unsubscribe from this group and stop receiving emails from it, >>>>> send >>>>> >>>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> >>>> To post to this group, send email to >>>>> kubernetes-users@googlegroups.com. >>>>> >>>> Visit this group at https://groups.google.com/grou >>>>> p/kubernetes-users. >>>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>> >>>>> >>> >>>>> >>> -- >>>>> >>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> >>> "Kubernetes user discussion and Q&A" group. >>>>> >>> To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> >>> email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> >>> To post to this group, send email to >>>>> kubernetes-users@googlegroups.com. >>>>> >>> Visit this group at https://groups.google.com/grou >>>>> p/kubernetes-users. >>>>> >>> For more options, visit https://groups.google.com/d/optout. >>>>> >> >>>>> >> -- >>>>> >> You received this message because you are subscribed to the Google >>>>> Groups >>>>> >> "Kubernetes user discussion and Q&A" group. >>>>> >> To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> >> email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> >> To post to this group, send email to kubernetes-users@googlegroups. >>>>> com. >>>>> >> Visit this group at https://groups.google.com/grou >>>>> p/kubernetes-users. >>>>> >> For more options, visit https://groups.google.com/d/optout. >>>>> > >>>>> > >>>>> > -- >>>>> > You received this message because you are subscribed to the Google >>>>> Groups >>>>> > "Kubernetes user discussion and Q&A" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>> send an >>>>> > email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> > To post to this group, send email to kubernetes-users@googlegroups. >>>>> com. >>>>> > Visit this group at https://groups.google.com/group/kubernetes-users >>>>> . >>>>> > For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> To post to this group, send email to kubernetes-users@googlegroups.com >>>>> . >>>>> Visit this group at https://groups.google.com/group/kubernetes-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Kubernetes user discussion and Q&A" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>>> To post to this group, send email to kubernetes-users@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/kubernetes-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-users+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
