Hey Arthur, On Fri, Sep 21, 2018 at 6:33 PM Артур Скок <[email protected]> wrote:
> It's just MHO. > But if *configuration_changed* returns 0 at next iteration, then the > device will never update. > I don't think so: if the configuration changes in the controller again, the checksum will be different and the configuration will be updated. If the configuration does not change in the controller, the checksum will be identical and updating won't be needed, especially if there was some error, we don't want the device to keep trying to apply a bugged configuration because that could make the network VERY unstable, think about a mesh network: if the wireless configuration of a group of devices is disrupted every 5 minutes the mesh won't work! Same for publicwifi: if the public wifi configuration is reloaded every 5 minutes users will be disconnected and won't be able to use the wifi. > In most cases with default testing procedure it works. Except one: if for > some reasons the controller doesn't return status 200OK for checksum > request (bad channel, connection gap... etc) then the device will be stuck. > In other words, if there is the controller's temporal problem or connection > problem but new configuration is correct. > If the device can't reach the controller it won't even be able to download the configuration in the first place and this case won't even happen. I think you are focusing on a very exceptional case, I've never seen any device to fail the test for a network connection issue right after the config was applied. in 100% of the cases that I've tested this feature, when the test failed, the config was broken. > In case of using custom test script, there are may exist other metrics > that can lead to a "failed test". But config will be fine. > We added to agent script next logic: we save last successful checksum and > compare this one with controller's checksum at *configuration_changed*(). > Yep, it leads to applying and testing even bad configuration each > iteration but it's more failsafe. > If the test fails, it means the configuration is broken. If the test fails but the config is not broken, then your test is broken and you need to improve your test so it fails only when the config is really broken. *A failed configuration test means: "this configuration is breaking our network and disrupting our service; we can't accept it, we must restore the previous state to ensure the service goes back to normal".* If you can explain a bit more what kind of custom test you are doing I may be able to understand your use case more in detail. Federico -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
