Puppet users - Jul 2010 - 0.24.8: puppetd --onetime and schedules?

I have a custom schedule to apply changes to various classes (e.g.,
"File { schedule => normal }").  This works fine for puppetd
running as
a daemon.  However, I note that if I run puppetd with the --onetime
option, it applies none of my actions.  puppetd --test will apply them,
and the normal puppetd run by the daemon will as well (just a few
minutes later).

Is there an issue with --onetime and schedules?  Is there something else
that needs to be supplied to make --onetime work as expected (aside from
--ignoreschedules; I don''t want to ignore schedule limitations,
I''d like
to apply whatever would apply that the schedule would permit).

If I can provide more details, please let me know.
-Alan


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Howdy Alan,

On 7/21/2010 6:04 PM, Alan Sparks wrote:
> I have a custom schedule to apply changes to various classes (e.g.,
> "File { schedule => normal }").  This works fine for puppetd
running as
> a daemon.  However, I note that if I run puppetd with the --onetime
> option, it applies none of my actions.  puppetd --test will apply them,
> and the normal puppetd run by the daemon will as well (just a few
> minutes later).
>
> Is there an issue with --onetime and schedules?  Is there something else
> that needs to be supplied to make --onetime work as expected (aside from
> --ignoreschedules; I don''t want to ignore schedule limitations,
I''d like
> to apply whatever would apply that the schedule would permit).
>
> If I can provide more details, please let me know.
> -Alan
I pretty much use this setup.  My clients run randomly once an hour for
most operations.  Disk intensive operations (package installs) are dealt
with during the configured schedule.   My configuration has something
that looks like this:

  class Foo {
    package {
      bar:
        schedule => daily, ensure => present;
    }
  }

any operation that I want to restrict includes the schedule.

Cheers,
Ryan


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Ryan Dooley wrote:
>  Howdy Alan,
>
> On 7/21/2010 6:04 PM, Alan Sparks wrote:
>   
>> Is there an issue with --onetime and schedules?  Is there something
else
>> that needs to be supplied to make --onetime work as expected (aside
from
>> --ignoreschedules; I don''t want to ignore schedule
limitations, I''d like
>> to apply whatever would apply that the schedule would permit).
>>     
>
> I pretty much use this setup.  My clients run randomly once an hour for
> most operations.  Disk intensive operations (package installs) are dealt
> with during the configured schedule.   My configuration has something
> that looks like this:
>
>   class Foo {
>     package {
>       bar:
>         schedule => daily, ensure => present;
>     }
>   }
>
> any operation that I want to restrict includes the schedule.
>
> Cheers,
> Ryan
>   
And are you using --onetime to trigger these random runs, via cron or
something?
-Alan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> And are you using --onetime to trigger these random runs, via cron or
> something?
> -Alan
>
We run puppet from cron via wrapper.  The wrapper looks for a file that
signals "not to run" if we are in a maintenance mode.

Cheers,
Ryan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.