I'm not so sure about your second possible expectation, but I was thinking of the first, that only one such promise would exist. I can, however, see an argument for any or all of a dist's class existing at any given time, rather than being mutually exclusive, as it's really a matter of personal interpretation whether the check for each possible class of a dist should be evaluated independently or relative to one another.
I could even see having the option to specify what kind of dist you want, one that allows either single or multiple classes to be defined. It would depend on how you want to use them. I may want to create two mutually exclusive promises that are evaluated, for example, 25% and 75% of the time, respectively. On the other hand, I may have several unrelated promises which I want to evaluate probabilistically but otherwise don't care if they happen to run during the same agent execution. Justin -----Original Message----- From: Daniel V Klein [mailto:d...@lonewolf.com] Sent: Thursday, March 11, 2010 1:02 PM To: Justin Lloyd Cc: Mark Burgess; help-cfengine@cfengine.org Subject: Re: Defining classes using "dist" This looks like a bug - although reading the code, I am not sure where it is. Even setting the persist time to 0 doesn't change things, but what I am seeing is not what I'd expect. I would expect either "n% of the time, you will see exactly one class_n" or else "n% of the time, you will see all the classes which are class_n or above (or below)". The distribution of classes below satisfies neither constraint. howl# cf-agent -Kf ./foo.cf R: d50 R: d30 howl# cf-agent -Kf ./foo.cf R: d50 R: d20 howl# cf-agent -Kf ./foo.cf R: d50 R: d10 howl# cf-agent -Kf ./foo.cf R: d10 R: d20 howl# cf-agent -Kf ./foo.cf R: d10 R: d50 R: d30 body common control { bundlesequence => { "testbundle" }; } bundle agent testbundle { classes: "d" dist => {10,20,30,50}, Zclasses => immediate; reports: d_10:: "d10"; d_20:: "d20"; d_30:: "d30"; d_50:: "d50"; } body classes immediate { persist_time => "0"; } > Mark, > > I just re-read the documentation on this (since I'm going back to fill > in comments in my policy files) and noticed that the notes for dist say > that it assigns "one generic class (always) and ONE additional class" > (emphasis mine), e.g. my_dist and my_dist_10. That makes it sound like > the result I saw where two such classes were defined (see below) was > erroneous. Which is correct, the behavior or the documentation? > > By the way, I remember in class when you were discussing this feature > and I wondered when you'd ever want it. Now I know, so thanks for such a > great feature! :) > > Thanks, > Justin > > -----Original Message----- > From: Mark Burgess [mailto:mark.burg...@iu.hio.no] > Sent: Wednesday, March 10, 2010 12:25 PM > To: Justin Lloyd > Cc: help-cfengine@cfengine.org > Subject: Re: Defining classes using "dist" > > > I mean the reevaluation of dist classes. > > Don't open a ticket, I already reported this. > > Justin Lloyd wrote: > > Which part, the re-evaluation of the dist class on each iteration or > the > > existence of multiple classes from the same base dist class? I'll open > a > > ticket based on your response. > > > > Thanks, > > Justin > > > > -----Original Message----- > > From: Mark Burgess [mailto:mark.burg...@iu.hio.no] > > Sent: Wednesday, March 10, 2010 12:11 PM > > To: Justin Lloyd > > Cc: help-cfengine@cfengine.org > > Subject: Re: Defining classes using "dist" > > > > > > This sounds like a bug. > > > > Justin Lloyd wrote: > >> This is just an FYI post, so feel free to ignore my rambling if > you're > >> not interested in some slightly deeper mechanics. :) > >> > >> So, I've learned something this morning. As I recall from reading, > >> Cfengine iterates its agent ordering (vars, classes, etc.) up to > three > >> times. A close examination of verbose agent output shows this in > lines > >> like "files in bundle dg (1)", etc. > >> > >> In further diagnosing an issue I'm having, I noticed that the > >> dist_percent class I created is evaluated during each such ordering > >> iteration, rather than once for each invocation of cf-agent as I had > >> originally thought. Thus, my promise that is conditional based upon > > the > >> existence of dist_percent_1 might be evaluated during the second > >> iteration, where dist_percent_1 might be true for any or none of the > >> three iterations of a given cf-agent invocation. So rather than my > >> original statement that cf-agent runs 288 times per day (12 times per > >> hour * 24 hours), the dist promise happens up to three times as > often, > >> meaning the number of times dist_percent_1 being defined is not 1% of > >> 288 but 1% of 288*3, or 2.8*3 = 8-9 times per day. > >> > >> However, since the specific class promise I want evaluated only > > happens > >> during one of the three ordering iterations, the chances of > >> percent_dist_1 occurring during the iteration when the desired > promise > >> would be evaluated would be 1/3rd of the total percent, bringing it > > back > >> down to the original 2-3 times per day. I only discuss this since it > > is > >> good to understand the actual mechanics of what is happening with > dist > >> promises. > >> > >> On a related note, I had another question in my mind answered by > > verbose > >> output during my testing: > >> > >> nova> ========================================================= > >> nova> classes in bundle asset (3) > >> nova> ========================================================= > >> nova> > >> nova> > >> nova> + Private classes augmented: > >> nova> + dist_percent_99 > >> nova> + dist_percent > >> nova> + dist_percent_1 > >> nova> + fetched_asset_data > >> nova> + dg_runtime_gold > >> > >> As you can see, dist classes are NOT mutually exclusive, as the _1 > and > >> _99 classes are both defined at the same time during this particular > >> iteration of the asset bundle. I wasn't sure from the documentation > >> whether this was the case, but this confirms it. The documentation > > does > >> state, however, that the base dist_percent class would always be > >> defined. > >> > >> Justin > >> > >> > >> -----Original Message----- > >> From: help-cfengine-boun...@cfengine.org > >> [mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Justin Lloyd > >> Sent: Wednesday, March 10, 2010 10:02 AM > >> To: nwat...@symcor.com > >> Cc: help-cfengine@cfengine.org; help-cfengine-boun...@cfengine.org > >> Subject: RE: Evaluating a promise occasionally > >> > >> Now that I re-read the splayclass description in the morning when I'm > >> fresh and not in the evening when I'm worn out, I actually understand > >> it. For this specific case, however, it appears slightly too limited, > >> since I want the class defined 2-3 times per day. Splayclass can only > >> take "hourly" or "daily" as its second argument. > >> > >> At least now I know I can use it for other stuff in the future now > > that > >> I understand it. :) > >> > >> Thanks, > >> Justin > >> > >> -----Original Message----- > >> From: nwat...@symcor.com [mailto:nwat...@symcor.com] > >> Sent: Wednesday, March 10, 2010 9:58 AM > >> To: Justin Lloyd > >> Cc: help-cfengine@cfengine.org; help-cfengine-boun...@cfengine.org > >> Subject: RE: Evaluating a promise occasionally > >> > >> Splayclass? > >> > >> Sincerely, > >> -- > >> Neil Watson > >> 416-673-3465 > >> > >> 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 > >> _______________________________________________ > >> Help-cfengine mailing list > >> Help-cfengine@cfengine.org > >> https://cfengine.org/mailman/listinfo/help-cfengine > > > > -- > Mark Burgess > > ------------------------------------------------- > Professor of Network and System Administration > Oslo University College, Norway > > Personal Web: http://www.iu.hio.no/~mark > Office Telf : +47 22453272 > ------------------------------------------------- > > 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 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
