On Mon, 15 Feb 2010, func@xxxxxxxxxxxxxxxxxxxx wrote:
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"... ?
We need a reasonable timeout for 'host is not responding' and 'packets get swallowed by a misconfigured firewall'. And we definitely want a configureable time (and a separate one) for 'process is taking a long time and not SAYING anything'.
I think the problem is - how the ssl layer comprehends either of those. B/c I think we'll end up having to do some sort of keepalive across the channel when we have a running process we're waiting on an answer from.
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.
please do. :) -sv _______________________________________________ Func-list mailing list Func-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/func-list
