[Freedombox-discuss] FBx config mgmt update

[Nick Daly]

On Mon, Jul 23, 2012 at 8:18 AM,  <bnewbold at robocracy.org> wrote:
>
> On Sun, 22 Jul 2012, Nick M. Daly wrote:
>
>> Bryan, is this ready for me to add to the weekly images?  This might
>> solve FreedomBuddy's OpenVPN service control issues.
>
> It's waiting for review/consensus/merge, but at this point there have been
> no complaints so it's probably good to go?

I'll wait for review and for James to merge it upstream.  I'll also
look it over closely before adding it to the weekly images.

> Does Plinth or the freedombox
> foundation have licensing policy or guidelines? Should I delegate copyright
> to the foundation? Sort of a mountain over a molehill for this patch.

Plinth is AGPL3, so I just AGPL3ed FreedomBuddy.  I've heard nothing
about copyright reassignment or contributor agreements, so I'm
reserving my own copyrights for now, until asked otherwise.

> I should probably give the code a one-over and include a HOWTO; I'll do this
> tomorrow (tuesday).
>
> 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?).

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.