Hi, I find this very important. We are currently evaluating func to manage >500 systems in about 100 groups and this would be definitively something worth having. I can imagine that here we suffer somewhat from the stateless design of func - If you plan to run 20 commands on a large group (e.g. from a bash script) then for each command func needs to check all hosts. I have another suggestion: Could we not have a better distinction between command timeouts and communication timeouts? E.g. even for a long-running command the communication timeout (e.g. for connect() ...) could be short. That way we could skip the extra ping and absent hosts could then fail with a "soft error" or "host unreachable" error" that should be different from a "command error"... ? Regards, Schlomo PS: I have to admit that I did not yet dive into the code to understand how func handles multiple hosts (async multiprocessing, paralellization etc.). The above suggestion would clearly need to be part of that. On 15/02/10 20:57, Seth Vidal wrote: > Something we have had a number of problems with in func is when you want > to run a command on all your boxes but some of them are down and your > timeouts take FOREVER so you have to wait and wait and wait. I was > considering adding code to func in general that before any command was > run it would run a test.ping() with a 5s(configurable) timeout. Then > take the list of hosts which did not respond and weed them out of your > host spec for the main script. > > I've found that saves a lot of time, especially if you've added a high > --timeout b/c the process you want to run is likely to take a long time. > > thoughts? > > -sv > > _______________________________________________ > Func-list mailing list > Func-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/func-list _______________________________________________ Func-list mailing list Func-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/func-list
