I believe the pylint warning to be a false positive, so I disabled it
and added a comment explaining why.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
Description of `master_tries` config option:
- The number of attempts to connect to a master before giving up.
Set this to -1 for unlimited attempts. This allows for a master to have
downtime and the minion to reconnect to it later when it comes back up.
In 'failover' mode, it is the number of attempts for each set of masters.
In this mode, it will cycle through the list of masters for each attempt.
This is different than `auth_tries` because `auth_tries` attempts to
retry auth attempts with a single master. `auth_tries` is under the
assumption that you can connect to the master but not gain
authorization from it. `master_tries` will still cycle through all
the masters in a given try, so it is appropriate if you expect
occasional downtime from the master(s).
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
There is a race condition that occasionally happens when using
the TCP transport. When using the TCP transport, it will fire the
`__master_connected` event before returning from tcp.py's
`AsyncTCPPubChannel.connect_callback`. What sometimes happens is
that the event handler for `__master_connected` is executed before
the control is returned to `eval_master` in master.py. If this
happens, `self.connected` is not yet defined, since `eval_master`
defines it. The event handler for `__master_connected` tries to
access the not yet defined `self.connected` and an exception occurs.
One possible solution is to use `hasattr` to check if `self.connected`
is defined before accessing it in the `__master_connected` handler.
However, I think it is cleaner just to set `self.connected = False` in
`Minion.__init__`, that way this variable will be defined in all cases
and can be relied upon.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
