On Sat, 2005-11-05 at 08:19 +0100, Mark Burgess wrote:
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.
Ah, the difference between theory and praxis...
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?.
Running cfagent manually, no locks or splay, takes 10-20 seconds. I run
everything through subversion and the svn commit can take another 10-20.
This is just my smallish home network--the larger configurations I've
done can take up to a minute or two before a manual run of cfagent
complete. In all, around 30 seconds of time I have to wait before I can
test; which is frustrating in my book, particularly when you factor in
the time it can take to reload the daemon, but that overhead cannot be
done away with.
A secondary effect, less important but worth mentioning, is that
following the above method means that, if one is using version control
as a front-end to the copy source, as I am with Subversion, several
changes are committed to the repository throughout the development
process instead of just one. There are several potential drawbacks to
this. If commits are sent to e-mail (not a bad idea so all sys admins
know what others are doing), then there is a flurry of e-mail instead of
just one, which is annoying. If one reviews one's changes, one has to
diff through a number of failed attempts before one finds what has
actually happened. Small things, perhaps, but worth considering.
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.
The premise here is that it is always feasible to fully develop and test
one's changes before moving into "production". It certainly sounds good
and it holds true, in my experience, about 85-95% of the time. There
are, however, all too many situations where it simply isn't feasible to
setup a test environment which adequately models the production
environment--either the scope of the change does not warrant
the overhead of setting up a test environment or the production
environment simply cannot be modeled well.
When the premise fails, I resort to workflow #1 or #2, both of which are
ugly. What I'm looking for is a solution that covers that 5-15% with
minimal invasiveness to both my configuration or cfengine.
I don't see how adding locks manually helps you in this problem.
Locking manually would allow me to make short-lived ad-hoc changes as I
sometimes find necessary, without racing with cfagent's schedule or
sitting through manual runs of cfagent.
Oh well, I guess I'll resort to FileExists tests for the subsystems that
are most troublesome.
Wil