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 -- Wil Cooley <[EMAIL PROTECTED]> Naked Ape Consulting, Ltd
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
