[Freedombox-discuss] FBx config mgmt update

[bnewbold at robocracy.org]

On Mon, 23 Jul 2012, Nick Daly wrote:

>> Does anybody have thoughts on logical error handling behavior? Some of the
>> existing Plinth code (eg, hostname changer) would try to revert changes when
>> they failed; i'm not sure if that behavior should be implemented at the
>> exmachina (library/wrapper) level or left to application logic.
>
> Thinking about this, I'd like to know how Ex does two things:
>
> 1. Whether changes are atomic (how do we prevent the system from
> seeing a semi-changed state?).

Currently this is left to the application logic (separate set/save calls). 
I'll need to check if Augeas rolls back commits to multiple files if one 
of the files fails.

> 2. Whether failed changes aren't implemented.
>
> It seems like the least surprising behavior would be: if Ex can't save
> the changes, it rolls them back and raises an error.  That way, the
> system's never left in an undefined state, and the controlling
> application can decide whether to give it another go or just bail.

I meant at a higher level: the configuration file is saved, but restarting 
services depending on that configuration file fails. The easy solution 
with minimal surprise is to bubble up the service restart error message 
and wait for the user to reconfigure before restarting the service. 
Rolling back changes could result in large amounts of user-entered data 
being lost because of a small typo.

Some firmwares (pfSense) also implement a "test configuration" feature 
which reverts new changes after two minutes unless they are re-confirmed; 
this helps prevent bricking or user lockout due to misconfiguration. I 
think this is overkill for now.

-bryan