The fix for this is actually trickier than it looks, because in order to do what I consider to be the "best" fix, we would need to change the RPC schema. That is because NTP servers are specified on a per-rack-controller basis, not a per-shared-subnet basis.
So I think the best compromise for now is, when selecting the NTP server to provide for a rack controller, prefer subnets on VLANs with DHCP enabled. I've proposed a branch that does that[1].
The other bug here is that if spaces are changed, the "best routable NTP server" calculation changes, but the database triggers don't notice the changed spaces and don't recalculate the DHCP configuration. I feel like with the "choose DHCP-enabled VLANs first" change, this is a less likely to occur edge case, and should be handled as a separate bug.
The fix for this is actually trickier than it looks, because in order to do what I consider to be the "best" fix, we would need to change the RPC schema. That is because NTP servers are specified on a per-rack-controller basis, not a per-shared-subnet basis.
So I think the best compromise for now is, when selecting the NTP server to provide for a rack controller, prefer subnets on VLANs with DHCP enabled. I've proposed a branch that does that[1].
The other bug here is that if spaces are changed, the "best routable NTP server" calculation changes, but the database triggers don't notice the changed spaces and don't recalculate the DHCP configuration. I feel like with the "choose DHCP-enabled VLANs first" change, this is a less likely to occur edge case, and should be handled as a separate bug.
[1]: /code.launchpad .net/~mpontillo /maas/ntp- issues- -bug-1695083/ +merge/ 325037
https:/