LGTM, thanks On Tue, 28 Apr 2015 at 15:25 'Klaus Aehlig' via ganeti-devel < [email protected]> wrote:
> Otherwise the writing of the unlock can overtake the > configuration writing and if the wconfd gets killed > forcefully in that moment an incorrect state is left > on disk. If the calling job was not affected, then > once it will retry it will believe it succeeded already > because the lock is gone, hence leaving the configuration > in an inconsistent state. > > Signed-off-by: Klaus Aehlig <[email protected]> > --- > src/Ganeti/WConfd/Core.hs | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/Ganeti/WConfd/Core.hs b/src/Ganeti/WConfd/Core.hs > index 247d23b..59479e7 100644 > --- a/src/Ganeti/WConfd/Core.hs > +++ b/src/Ganeti/WConfd/Core.hs > @@ -141,7 +141,8 @@ writeConfigAndUnlock cid cdata = do > la <- readLockAllocation > if L.holdsLock cid ConfigLock L.OwnExclusive la > then do > - CW.writeConfigWithImmediate cdata $ unlockConfig cid > + CW.writeConfig cdata > + unlockConfig cid > return True > else do > logWarning $ show cid ++ " tried writeConfigAndUnlock without > owning" > -- > 2.2.0.rc0.207.ga3a616c > >
