On Wed, Apr 21, 2010 at 06:16:11PM -0400, Justin Lloyd wrote: >Dan, > >The part about classes being stored in a database has me confused. I >thought that classes were in-memory for each run of a component >(cf-agent, cf-serverd, etc.). Are you saying classes are something like >a shared value between the components, rather than each component >essentially having its own view of the world, so to speak?
It is possible to define "persistent" classes. I've not used them, but it should be possible in theory. Have a look at section 6.4.2, 11.65 (persistant classes from remote cfservd systems!), and 5.2.11. >I assume you're referring to cf_classes.tcdb. Can you elaborate a bit >more on how that file is used? The reference manual says the file is a >"database of classes that have been defined on the current host, >including their relative frequences, scaled like a probability". That >sounds to me like it's statistical/historical, rather than realtime, >information. I think that cf_state.tcdb is more appropriate: "A database of persistent classes active on this current host." > >Thanks, >Justin > >-----Original Message----- >From: d...@lonewolf.com [mailto:d...@lonewolf.com] On Behalf Of >daniel.kl...@cfengine.com >Sent: Wednesday, April 21, 2010 4:08 PM >To: Lebel, Marco >Cc: Justin Lloyd; fo...@cfengine.com; help-cfengine@cfengine.org >Subject: Re: Cfengine Help: Re: RE: Cfengine Help: cfengine program flow > > >Kinda-sorta :-) > >Classes that are defined in a "common" bundle are global. Classes that >are >defined in any other kind of bundle are local to that bundle. See >section >1.6 of the manual. > >Likewise, classes are cached with an expiration time, but they do go >away. >Although they can be set with a test, the condition which sets them is >not >continuously evaluated - so they stick around a bit. Classes are stored >in >a database - so that the various components of Cfengine can share them. >You can clear a class with the -U switch, if you need to. > >-Dan > >> Justin, >> >> You are bringing an interesting point since I struggle with classes in >this c >> ontext. But I have not done any structured testing but I am under the >impres >> sion that once a class has been set it never gets unset. >> >> Again I want to stress that I never did any exhaustive testing on this >but I >> believe that classes once set they are set globally (i.e. visible in >all subs >> equent bundle) and never get unset even if the condition that >initially creat >> ed it is no longer true... Again the key word is an impression that >needs to >> be confirmed by someone in the know or has done the necessary testing. >> >> Marco >> >> -----Original Message----- >> From: help-cfengine-boun...@cfengine.org >[mailto:help-cfengine-boun...@cfengi >> ne.org] On Behalf Of Justin Lloyd >> Sent: Wednesday, April 21, 2010 5:31 PM >> To: fo...@cfengine.com; help-cfengine@cfengine.org >> Subject: RE: Cfengine Help: Re: RE: Cfengine Help: cfengine program >flow >> >> As I understand it, it will reevalute the class promise, and therefore >> check for the file's existence, on all three iterations. A good way to >> see what is happening is to run cf-agent in verbose mode (cf-agent >-vK) >> and write its output to a file then read through it. You'll see lines >> like this (yours will be prefixed with something other than "nova>"): >> >> [r...@rhn ~]# cf-agent -vK > /tmp/out >> [r...@rhn ~]# grep '^nova>.* in bundle .* ([1-3])' /tmp/out >> nova> vars in bundle def (1) >> nova> classes in bundle def (1) >> nova> vars in bundle def (2) >> nova> classes in bundle def (2) >> nova> vars in bundle def (3) >> nova> classes in bundle def (3) >> nova> vars in bundle update (1) >> nova> classes in bundle update (1) >> nova> processes in bundle update (1) >> nova> commands in bundle update (1) >> nova> files in bundle update (1) >> nova> services in bundle update (1) >> nova> vars in bundle update (2) >> nova> classes in bundle update (2) >> nova> processes in bundle update (2) >> nova> commands in bundle update (2) >> nova> files in bundle update (2) >> nova> services in bundle update (2) >> nova> vars in bundle update (3) >> nova> classes in bundle update (3) >> nova> processes in bundle update (3) >> nova> commands in bundle update (3) >> nova> files in bundle update (3) >> nova> services in bundle update (3) >> nova> vars in bundle dg (1) >> nova> classes in bundle dg (1) >> nova> vars in bundle dg (2) >> nova> classes in bundle dg (2) >> nova> vars in bundle dg (3) >> nova> classes in bundle dg (3) >> >> Note how it does 3 iterations of the promise types in bundle "def", >then >> 3 of bundle "update", etc. ("dg" is a custom bundle of mine). >> >> Justin >> >> -----Original Message----- >> From: help-cfengine-boun...@cfengine.org >> [mailto:help-cfengine-boun...@cfengine.org] On Behalf Of >> fo...@cfengine.com >> Sent: Wednesday, April 21, 2010 3:22 PM >> To: help-cfengine@cfengine.org >> Subject: Cfengine Help: Re: RE: Cfengine Help: cfengine program flow >> >> Forum: Cfengine Help >> Subject: Re: RE: Cfengine Help: cfengine program flow >> Author: nicolas >> Link to topic: >> https://cfengine.com/forum/read.php?3,16959,16960#msg-16960 >> >> thanks for the fast response. >> >it helps, i thought this is a recommendation :-/ (i should read more >> exactly) >> >> but one question i still have: >> >> if i define a class: >> >> classes: >> >> "xy_installed" expression => fileexists("/usr/example"); >> >> does it recheck this value each time i use >> >> xy_installed:: >> >> or only once at the beginning of each of the 3 times? >> >> regards >> >> nicolas >> >> _______________________________________________ >> Help-cfengine mailing list >> Help-cfengine@cfengine.org >> https://cfengine.org/mailman/listinfo/help-cfengine >> >> This electronic communication and any attachments may contain >confidential an >> d proprietary >> information of DigitalGlobe, Inc. If you are not the intended >recipient, or a >> n agent or employee >> responsible for delivering this communication to the intended >recipient, or i >> f you have received >> this communication in error, please do not print, copy, retransmit, >dissemina >> te or >> otherwise use the information. Please indicate to the sender that you >have re >> ceived this >> communication in error, and delete the copy you received. DigitalGlobe >reserv >> es the >> right to monitor any electronic communication sent or received by its >employe >> es, agents >> or representatives. >> >> _______________________________________________ >> 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 > >This electronic communication and any attachments may contain confidential and >proprietary >information of DigitalGlobe, Inc. If you are not the intended recipient, or an >agent or employee >responsible for delivering this communication to the intended recipient, or if >you have received >this communication in error, please do not print, copy, retransmit, >disseminate or >otherwise use the information. Please indicate to the sender that you have >received this >communication in error, and delete the copy you received. DigitalGlobe >reserves the >right to monitor any electronic communication sent or received by its >employees, agents >or representatives. > >_______________________________________________ >Help-cfengine mailing list >Help-cfengine@cfengine.org >https://cfengine.org/mailman/listinfo/help-cfengine -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
