RE: Locking for temporary ad-hoc changes?

[Mark Burgess]

I can see that there might be a reason to do this, but it sort of
breaks with the cfengine recommended usage to be editing files by hand
while you are in production.

I don't see how cfengine adds a large and frustrating latency. If you
want an immediate test, then just run cfagent by hand or use cfrun,
which is what you say in 1 - so...what?.

Number 2 I don't understand at all. It sounds as though you are openly
violating the basic modus operandi of cfengine. Either you are letting
cfengine manage a file or you are doing it by hand. If what you are
doing is a contradction in itself then cfengine cannot really be blamed.

My recommendation is that you do not export your altered configuration
file for distribution until after it is tested. That means that you edit
files in a location that is not the same as that from which you
distribute, otherwise you can send half-edited versions out to your
hosts. I would recommend a hook to your "commit" to repository for that.

I don't see how adding locks manually helps you in this problem.

M

On Fri, 2005-11-04 at 13:46 -0800, Wil Cooley wrote:
> On Fri, 2005-11-04 at 08:51 +0100, Mark Burgess wrote:
> > I have scaned but I'm not sure that I understand this discussion. Can
> > you spell out the conclusions for me?
> 
> My request is for an admin-initiated locking mechanism, so that making
> changes which require several tries to get right can be done more
> smoothly.  My example was Apache config files, which sometimes require
> several tries to get right (think fancy stuff with mod_rewrite, for
> example).  Current cycle is one of these:
> 
> 1. Work on cfserver or working directory in SCM:
>     until correct:
>       edit config file
>       commit to repository
>       manually run cfagent on target host
>       test config file
> 
> In this case running cfagent adds a large and frustrating latency
> between edit/test.  I tend to try to use this method, but works best for
> minor changes or changes where I can properly validate that everything
> is correct without HUPping a daemon or putting into whatever environment
> it needs to be in.
> 
> 2. Work on target host:
>     until correct:
>         edit config file
>         check cfagent hasn't overwritten config file
>         test config file
>         check cfagent hasn't overwritten config file
>     commit to repository
>  
> This is what I do often; I know roughly when cfagent is going to run and
> Vim is good about letting me know when the file's been overwritten.
> Clearly, this is hackish and prone to race conditions.
> 
> Another suggested approach is:
> 
> 3. Work on target host:
>     kill cfexecd
>     until correct:
>         edit config file
>         test config file
>     commit to repository
>     restart cfexecd
> 
> This works without the race conditions, except it prevents cfengine from
> being able to do anything else while I'm working on one file and is open
> to forgetting to restart cfexecd (or requiring an external framework to
> ensure that it's working).
> 
> The requested feature is to allow locking of files on the target host to
> prevent modifications while locked, which would permit this kind of work
> flow:
> 
> 4. Work on target host:
>     lock config file
>     until correct:
>         edit config file
>         test config file
>     commit to repository
>     unlock config file
> 
> I envisage this as being implemented by a tool which adds, removes or
> lists locks, even if just a flat list of files in /var/cfengine
> somewhere.  Before cfagent initiates a copy: or files: change (but after
> it has decided to), cfagent checks for the lock and sends an alert if
> the file is locked but skips modification.
> 
> Wil