Thanks for the explanation Luke, now it made sense to me as in when to
use notify and subscribe.
I did some further tests on schedule with the following class:
class scheduletest {
exec { "date >> /var/tmp/scheduletest-hourly.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => hourly,
creates => "/var/tmp/schedultest.txt",
}
exec { "date >> /var/tmp/scheduletest-daily.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => daily,
creates => "/var/tmp/schedultest-daily.txt",
}
exec { "date >> /var/tmp/scheduletest-weekly.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => weekly,
creates => "/var/tmp/schedultest-weekly.txt",
}
exec { "date >> /var/tmp/scheduletest-puppet.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => puppet,
creates => "/var/tmp/schedultest-puppet.txt",
}
exec { "date >> /var/tmp/scheduletest-atnight.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => atnight,
creates => "/var/tmp/schedultest-atnight.txt",
}
exec { "date >> /var/tmp/scheduletest-lunchhour.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => lunchhour,
creates => "/var/tmp/schedultest-lunchhour.txt",
}
exec { "date >> /var/tmp/scheduletest-often.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => often,
creates => "/var/tmp/schedultest-often.txt",
}
exec { "date >> /var/tmp/scheduletest-afternoontest.txt":
path => "/usr/bin:/usr/sbin:/bin",
schedule => afternoontest,
creates => "/var/tmp/schedultest-afternoontest.txt",
}
exec { "date >> /var/tmp/scheduletest-always.txt":
path => "/usr/bin:/usr/sbin:/bin",
creates => "/var/tmp/schedultest-always.txt",
}
schedule { "lunchhour":
range => "12 - 13",
repeat => 3,
}
schedule { often:
repeat => 12,
period => hourly,
}
schedule { "afternoontest":
range => "13 - 18",
repeat => 6,
}
schedule {
atnight:
range => "20:00 - 22:00",
period => daily,
}
}
The results are as follows:
scheduletest-always: benchmark, ran every half an hour (the default
every half an hour)
scheduletest-hourly: as expected, new entry was created once an hour,
at the time when puppetd was due to kick off
scheduletest-daily: ran once a day, and by default had a minimum a
day's distance between runs
scheduletest-weekly: presumably will run only once a week - but the
default is a week's distance between runs so I think periodmatch
should be used to tweak that to the desired time, in combination with
range
scheduletest-puppet: kicks off everytime puppet runs, is this any
different than not specifying anything at all?
scheduletest-atnight: actually worked as expected - i guess i didn't
wait long enough and puppetmaster was keeping persistent tracking of
runs :P Range combined with daily ensured it only ran once that day;
but if the default periodmatch is 'distance', and as the run time
drifts down (e.g. ran night before at 20:29, and last night at 20:31),
could this reach a point the drift would past the range and a day get
skipped?
afternoontest/often/lunchhour: all aimed at testing 'repeat', however
I couldn't see how the number of repeats made any difference. In the
case of 'often', the result was same as always - i.e. ran once every
half an hour (probably as expected). And afternoontest, which I would
suppose to run no more than 6 times in the range, ran 10 times as if
there were no repeat set and just the range.
So for my requiremnt, combination of daily, range and periodmatch
should do the trick, but I would be interested to find out how repeat
works tho.
Kind regards,
Hui
On Mar 25, 2:36 am, Luke Kanies <[email protected]> wrote:
> On Mar 23, 2009, at 7:21 AM, iuhh wrote:
>
>
>
>
>
> > Hi guys,
>
> > I am new to puppet and got a question regarding subscribing and
> > scheduling. As we are going to run puppet on production machines
> > certain operations can only be performed out-of-hours, e.g. management
> > of ntp and syslog.
>
> > Take NTP for instance, I needed to distribute the configuration and
> > restart the service afterwards, but only if it's between 20:00 to
> > 22:00. I thought of following ways:
> > - schedule on exec and exec subscribe to file: didn't work, the
> > conditions are 'OR'ed
> > - file notify exec, schedule on exec: didn't work, triggering are also
> > 'OR'ed
> > - schedule on file, exec subscribe to file (see below config)
> > - schedule on file, file notify exec (gives same result as above)
>
> > So I arrived at the following configuration:
>
> > class ntp {
>
> > package { ntp: ensure => latest }
>
> > file { "/etc/ntp.conf":
> > ensure => present,
> > mode => 444,
> > owner => root,
> > group => root,
> > source => "puppet:///ntp/ntp.conf",
> > schedule => atnight,
> > }
>
> > service { ntpd:
> > enable => true,
> > ensure => true,
> > hasrestart => true,
> > hasstatus => true,
> > }
>
> > schedule { atnight:
> > range => "20 - 22",
> > period => daily,
> > }
>
> > exec { "reload_ntp":
> > path => "/usr/bin:/usr/sbin:/bin",
> > subscribe => File["/etc/ntp.conf"],
> > refreshonly => true,
> > # Explicitly avoid init.d/ntpd restart as it uses ntpdate
> > # Needs tweaking to accomondate other OSes
> > refresh => "/etc/init.d/ntpd stop && ntpd -u ntp:ntp -p /var/
> > run/ntpd.pid -g",
> > }
>
> > }
>
> > When I run puppetd during testing inside the time range, it would
> > complain about the schedule:
> > debug: //Node[testhost]/ntp/Exec[reload_ntp]/subscribe: subscribes to
> > File[/etc/ntp.conf]
> > debug: //Node[testhost]/ntp/File[/etc/ntp.conf]: Not scheduled
>
> I think you've got the schedule a bit wrong - I think Puppet's
> interpreting that as saying "only run this between the 20th and 22nd
> day". Try 'hourly' as the period.
>
> I don't use schedules much, so I could be completely wrong, even
> though I wrote the code.
>
>
>
> > I've attempted to tweak the range (e.g. range => "08:00 - 22:00",
> > range => [08, 22] which resulted Parameter range failed: Invalid range
> > value error), changed period => hourly, added repeat => 10 (I
> > understand this counts number of invocations during the range in the
> > given period?), and restarted puppetmasterd in attempt to clear any
> > counters (are they persistent?), none of which made it run.
>
> > Could you help? I'm running puppet 0.24.5.
>
> > On a separate note, how is notify different from subscribe in terms of
> > practical use? I noticed both would work (e.g. add notify => Exec
> > ["reload_ntp"] in the file resource and get rid of subscribe in the
> > exec resource), what is the best scenario to use either?
>
> Notify and subscribe are opposites, and you should use whichever is
> easier. Generally, you want to specify the relationship on the "many"
> side of the edge; e.g., if you have many apache virtual hosts and one
> apache process, then each virtual host would notify the process.
>
> --
> Silence is a text easy to misread.
> -- A. A. Attanasio, 'The Eagle and the Sword'
> ---------------------------------------------------------------------
> Luke Kanies |http://reductivelabs.com|http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
