"The important thing to understand about how schedules are currently
implemented in Puppet is that they can only be used to stop an element
from being applied, they never guarantee that it is applied."
A schedule does not say this will happen this often, it says this can
not happen more than this often. Thus with the default half hour
updates the proposed schedule would not have any effect and the
maximum out of date time would be 30 minutes. You can however
increase the poll time for puppetd by configuring the runinterval
(http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference).
Then you could use schedules to limit how often less volatile
resources are checked.
Another option for triggering a sync would be to use puppetrun,
however this would require you to have the appropriate ssl certs
distributed.
Thanks
Brian
On Nov 12, 2007 8:31 AM, Mike Renfro <renfro at tntech.edu>
wrote:> On 11/12/2007 3:19 AM, Brice Figureau wrote:
> > Can you think about a more puppet-like way of doing things which
> > guarantees each puppetd can see the same data file at about the same
> > time ?
>
> Schedule: http://reductivelabs.com/trac/puppet/wiki/TypeReference#id41
>
> schedule { veryoften:
> period => hourly,
> repeat => 6
> }
>
> exec { "someupdater":
> schedule => veryoften
> }
>
> The above will run "someupdater" up to 6 times per hour, which if
the
> update procedure is quick enough, would mean nobody is more than 10
> minutes out of sync with anyone else.
>
> --
> Mike Renfro / R&D Engineer, Center for Manufacturing Research,
> 931 372-3601 / Tennessee Technological University
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users at madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
