You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is related to #21 but I've found this to be a broader issue in that any error condition on a set operation will still change the config file even though it "failed". This seems to not be a good behavior for the faucetagent to have? Perhaps it should copy the original faucet.yaml before applying set, and if it returns a failure then it sets it back to what the original faucet.yaml was?
This is especially bad in cases where the faucet.yaml being applied is valid, but there was a "failure" in the set operation for some other reason and Faucet is now running that newly applied config but the end user of faucetagent was told it failed.
The text was updated successfully, but these errors were encountered:
Hmm.... I have to think about it, but my immediate take is this:
If the config change fails to complete successfully, then FAUCET's state is suspect, so you should reapply it via the agent and verify that it has been applied successfully.
We could, however, add a mechanism to check whether a config change has been applied, by validating the hash against what FAUCET is reporting.
This is related to #21 but I've found this to be a broader issue in that any error condition on a
set
operation will still change the config file even though it "failed". This seems to not be a good behavior for the faucetagent to have? Perhaps it should copy the originalfaucet.yaml
before applying set, and if it returns a failure then it sets it back to what the originalfaucet.yaml
was?This is especially bad in cases where the
faucet.yaml
being applied is valid, but there was a "failure" in theset
operation for some other reason and Faucet is now running that newly applied config but the end user of faucetagent was told it failed.The text was updated successfully, but these errors were encountered: