One advantage of the two-stage copy is you can use it to detect when the source file changed - and then drive a latter action based on that.
E.g. in the first copy (the staging copy), set a class like "source_updated" if "promise_repaired". Then make the second copy dependent on "source_updated" - this will allow the final final to change (maybe you permit some local edits to the final file) without cfengine updating it until a new version of the source file is available. On Thu, Sep 16, 2010 at 8:02 PM, Jan Kundrát <j...@gentoo.org> wrote: > Dear list, > we've been using Cfengine version 2 for a few years. We're a W-LCG > computing facility with roughly 350 machines and 2600 CPUs and our "job" > is to deliver CPU power and disk space to grid users, especially > particle physicists. > > I've learned from various tutorials, articles and other resources that > it's recommended to do a two-phase copy when dealing with file copies -- > at first, files get transfered to a local area on the local disk, and > only then they got copied to their final destination in the filesystem. > I also got the feeling that it's normal to copy "all files" into each > node's staging area, even if such files are not needed on that > particular machine. > > I'd like to ask if that is indeed the "usual setup" or "best practices" > in the cfengine-land. What are the reasons for that? I wonder why is > there the need to do the copy in two phases (that's my first question) > and the second one is why to copy all files for all services to each > machine. > > It would help me to better comprehend cfengine, so thanks :). > > With kind regards, > Jan > > -- > cd /local/pub && more beer > /dev/mouth > > > _______________________________________________ > Help-cfengine mailing list > Help-cfengine@cfengine.org > https://cfengine.org/mailman/listinfo/help-cfengine > >
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
