Adds an optional new configuration format under the remote hosts
configuration segment, allowing the specification of a weight in
addition to the host name.
Weights are used to refactor the active "count" of a host in order to
bring it lower by the following logic:
1. If a host's weight is not specified, it is 1.
2. If a host's weight is 1, its "weighted_count" is equal to its
"count".
3. If a host's weight is greater than 1, its "weighted_count" is equal
to the floor division of its real "count" and its "weight".
So for example, if there are 2 hosts with weights 1 and 2, and there is
currently 1 process running against each, the "weighted_count"s would
be:
host1: 1
host2: 1//2 = 0
And thus host2 would be considered the "least loaded" host. Then, if
another process started:
host1: 1
host2: 2//2 = 1
Resulting in the last host on the list (the first to run a process)
getting the next one, and so on.
This logic should make sense, but I cannot extensively test it.
Closes#8 aspect 1 (aspect 2 is out-of-scope)
1. Split the command string into an "rffmpeg_ssh_command" and
"rffmpeg_ffmpeg_command". The first contains the SSH arguments, the
second contains anything run on the remote system. For consistency,
also rename the local command string to "rffmpeg_ffmpeg_command". Join
these commands commands together as rffmpeg_command before executing on
the remote host.
2. The split is done so that the output log can properly quote the SSH
remote portion with single-quotes, thus avoiding BASH syntax errors on
parenthesis characters which do not seem to cause a problem for
subprocess itself, when manually running the printed command. Helps
address confusion in #10.
3. Reorganize the functions to better reflect their order.
4. Improve logging by removing some superfluous messages and making
others clearer.
When a pipe symbol is introduced in any ffmpeg flag bash tries to pipe
the output to the second half of the command instead of passing it to
ffmpeg. Therefore it is necessary to escape
Fall back to using the local ffmpeg binary (at the same path as the
remote system) if we are unable to reach a remote server. Prevents
rffmpeg from getting stuck if it can find no valid remote servers.
Allow rffmpeg to determine if a host is "bad", i.e. if the SSH
connection times out or fails, for instance due to an unreachable host
down for maintenance. In such a case, instead of exiting abruptly, we
will mark the host as "bad" in the current state file, and then retry
the whole process, skipping the bad hosts. If other rffmpeg processes
start while the current one is still running, they will also treat the
host as "bad", until the original process ends at which point the
statefile marking it bad will be removed and it will be retried by
future processes. This helps ensure that redundancy of transcode hosts
can actually be achieved, as before if the first host was down, the
process would simply fail, retry, and then fail again if the down host
was first in the list.
This required some major refactoring of the code, including
functionalizing various elements of the process as well as adding an
infinite loop to the main execution in order to keep looping through
hosts after marking one as bad.