On Sun, Feb 26, 2017 at 12:53 AM, 'mrpanigale' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
> Hi David, > > I am aware of this already being achievable via Daemonsets, although last > time I checked a Daemonset had to run on all nodes and did not honor a node > selector (this may have been fixed). > It does honor node selector. If you find that's not working, let us know. > Assuming that this has been fixed, it is often not desirable for a > "Puppet" script to run indefinitely. So with this analogy I dont find it > useful to package post deployment scripts as Daemonsets. > Right, understood. > For me the undesirable work around would be to deploy a higher-level > agent something like Fleet or Salt as a Daemonset and then run interpreted > scripts remotely. > > kind regards, > > Andrew > > On Saturday, February 25, 2017 at 9:34:26 PM UTC+1, David Oppenheimer > wrote: >> >> Just to be clear, DaemonSet does allow all of these >> > - Run or schedule a job on all machines >> > - Run or schedule a job on a sub-set of machines using a label selector >> > - Run or schedule a job on a single machine" >> >> It just requires that the "job" be a "run forever" thing, not a "run to >> completion" thing (hence not technically a Kubernetes Job). >> >> >> On Sat, Feb 25, 2017 at 8:26 AM, 'mrpanigale' via Kubernetes user >> discussion and Q&A <kubernet...@googlegroups.com> wrote: >> >>> I feel this feature is even more important with the deprecation of Fleet. >>> >>> "For me this is a very important issue but more in the broader scope of >>> Jobs (not just scheduled). >>> CoreOS has deprecated Fleet (distributed systemd). With Fleet one could >>> broadcast a global systemd unit to run on and update all machines in a >>> cluster with a label selector. >>> >>> Given a kubernetes cluster provisioned with no configuration management >>> tool such as Puppet, Fleet or Chef it would be logical for kubernetes to >>> support modification of its self using just kubernetes. This is why I >>> personally would like job scheduling choice: >>> - Run or schedule a job on all machines >>> - Run or schedule a job on a sub-set of machines using a label selector >>> - Run or schedule a job on a single machine" >>> >>> On Friday, January 20, 2017 at 7:26:37 PM UTC+1, Brandon Philips 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 <kubernet...@googlegroups.com> wrote: >>>> >>>>> Unfortunately I don't think it's possible. The documentation for >>>>> DaemonSet <https://kubernetes.io/docs/admin/daemons/> 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 <krma...@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-use...@googlegroups.com. >>>>>> To post to this group, send email to kubernet...@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-use...@googlegroups.com. >>>>> To post to this group, send email to kubernet...@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-use...@googlegroups.com. >>> To post to this group, send email to kubernet...@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.
