On 17 March 2014 00:39, Julian Edwards <email address hidden> wrote:
> On Friday 14 Mar 2014 09:37:18 you wrote:
> > I was adviced to try rebooting the MAAS server (region and cluster
> > controller on one box) which fixed the problem. But a subsequent reboot
> > brought it back :/
>
> The timeouts on the TFTP server are very generous, it uses a backoff
> algorithm
> and ends up as a few seconds. This should be more than enough for a local
> network!
This may be true for upstream MAAS (actually python-tx-tftp) but in the
packaged version all of the timeouts are 1s - see https://bugs.launchpad.net/maas/+bug/1155556 so it's not (1, 3, 7) but (1,
1, 1, 1, 1, 1)
The actual values of the timeouts aren't relevant for this bug, since the
issue (at least for me) was faulty networking configuration.
On 17 March 2014 00:39, Julian Edwards <email address hidden> wrote:
> On Friday 14 Mar 2014 09:37:18 you wrote:
> > I was adviced to try rebooting the MAAS server (region and cluster
> > controller on one box) which fixed the problem. But a subsequent reboot
> > brought it back :/
>
> The timeouts on the TFTP server are very generous, it uses a backoff
> algorithm
> and ends up as a few seconds. This should be more than enough for a local
> network!
This may be true for upstream MAAS (actually python-tx-tftp) but in the /bugs.launchpad .net/maas/ +bug/1155556 so it's not (1, 3, 7) but (1,
packaged version all of the timeouts are 1s - see
https:/
1, 1, 1, 1, 1)
The actual values of the timeouts aren't relevant for this bug, since the
issue (at least for me) was faulty networking configuration.