I have the following set up:
schedule {nightly:
period => daily,
range => "18 - 23",
repeat => 1
}
define deadlypkg {
tag("package")
$pkgrepo="/staging/PRODUCTION/deadly"
package{"$name":
source => "$pkgrepo/$name.pkg",
ensure => latest,
adminfile => "puppet",
schedule => nightly
}
}
class deadly {
deadlypkg{blah:}
}
This is all in a single manifest file, init.pp for the module
"deadly".
The node has "include deadly" in its definition.
(Don''t worry about the silly name, it''s a host-naming
thing...)
Inconsistently I get the following in the puppetd run output:
Feb 12 13:16:28 wrath puppetd[23298]: [ID 702911 daemon.warning] Not using cache
on failed catalog
Feb 12 13:16:28 wrath puppetd[23298]: [ID 702911 daemon.warning] Configuration
could not be instantiated: Could not find schedule nightly at
/staging/puppet/common/modules/deadly/manifests/init.pp:16
Sometimes, however, it seems to work OK.
Master and node are both running Puppet 0.24.7, though it was also
happening with the node at 0.24.6 (I just upgraded that to see if it
was a version mismatch problem). Both ends are running Solaris 10 U6,
master is SPARC, node is Opteron.
Any ideas?
Matt
--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
In an effort to figure out what might be causing the scheduling
problem I tried doing a fresh install:
root@wrath ~# ruby --version
ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-solaris2.10]
root@wrath ~# puppet --version
0.24.7
root@wrath ~# facter --version
1.5.3
root@wrath ~# uname -a
SunOS wrath 5.10 Generic_138889-03 i86pc i386 i86pc
And now there''s a new and exciting problem. It seems that puppetd
is no longer able to execute external commands (e.g., svcs, crontab).
The debug output looks like it''s running the right stuff, e.g.:
debug: Puppet::Type::Service::ProviderSmf: Executing ''/usr/bin/svcs -l
sma''
wrong number of arguments (2 for 1)
warning: Service[sma](provider=smf): Could not get status on service sma
But clearly whatever in Ruby is returning this "wrong number of arguments
(2 for 1)" error is blocking the execution of svcs (and crontab).
The only bright spot is that the schedule issue doesn''t *seem* to
be recurring, but that''s not very useful if puppetd can''t
actually
run anything.
I was previously using:
ruby 1.8.7 (2008-04-26 patchlevel 5000) [i386-solaris2.10]
which was the current pre-release when I originally did the Puppet
installs. I used that because the stable release broke Puppet in
some other exciting way I can no longer recall...
Matt
--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
This one was my own fault for not noticing the patched source tarballs. Switched to Ruby 1.8.7-p72 and this goes away. Now to see if it helps with the schedule problem. Matt McLeod wrote:> > In an effort to figure out what might be causing the scheduling > problem I tried doing a fresh install: > > root@wrath ~# ruby --version > ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-solaris2.10] > root@wrath ~# puppet --version > 0.24.7 > root@wrath ~# facter --version > 1.5.3 > root@wrath ~# uname -a > SunOS wrath 5.10 Generic_138889-03 i86pc i386 i86pc > > And now there''s a new and exciting problem. It seems that puppetd > is no longer able to execute external commands (e.g., svcs, crontab). > The debug output looks like it''s running the right stuff, e.g.: > > debug: Puppet::Type::Service::ProviderSmf: Executing ''/usr/bin/svcs -l sma'' > wrong number of arguments (2 for 1) > warning: Service[sma](provider=smf): Could not get status on service sma > > But clearly whatever in Ruby is returning this "wrong number of arguments > (2 for 1)" error is blocking the execution of svcs (and crontab). > > The only bright spot is that the schedule issue doesn''t *seem* to > be recurring, but that''s not very useful if puppetd can''t actually > run anything. > > I was previously using: > > ruby 1.8.7 (2008-04-26 patchlevel 5000) [i386-solaris2.10] > > which was the current pre-release when I originally did the Puppet > installs. I used that because the stable release broke Puppet in > some other exciting way I can no longer recall... > > Matt > > -- > * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * > --- People can do the work, so machines have time to think --- > > >-- * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * --- People can do the work, so machines have time to think --- --~--~---------~--~----~------------~-------~--~----~ 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 nope, it doesn''t: Feb 17 04:29:03 wrath puppetd[20155]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 04:46:51 wrath puppetd[20449]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 06:26:32 wrath puppetd[21618]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 09:15:18 wrath puppetd[23987]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Does anyone actually use scheduling in Puppet? Hell, at this point, is anyone other than me even reading this? Matt Matt McLeod wrote:> > This one was my own fault for not noticing the patched source > tarballs. Switched to Ruby 1.8.7-p72 and this goes away. > > Now to see if it helps with the schedule problem. > > Matt McLeod wrote: > > > > In an effort to figure out what might be causing the scheduling > > problem I tried doing a fresh install: > > > > root@wrath ~# ruby --version > > ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-solaris2.10] > > root@wrath ~# puppet --version > > 0.24.7 > > root@wrath ~# facter --version > > 1.5.3 > > root@wrath ~# uname -a > > SunOS wrath 5.10 Generic_138889-03 i86pc i386 i86pc > > > > And now there''s a new and exciting problem. It seems that puppetd > > is no longer able to execute external commands (e.g., svcs, crontab). > > The debug output looks like it''s running the right stuff, e.g.: > > > > debug: Puppet::Type::Service::ProviderSmf: Executing ''/usr/bin/svcs -l sma'' > > wrong number of arguments (2 for 1) > > warning: Service[sma](provider=smf): Could not get status on service sma > > > > But clearly whatever in Ruby is returning this "wrong number of arguments > > (2 for 1)" error is blocking the execution of svcs (and crontab). > > > > The only bright spot is that the schedule issue doesn''t *seem* to > > be recurring, but that''s not very useful if puppetd can''t actually > > run anything. > > > > I was previously using: > > > > ruby 1.8.7 (2008-04-26 patchlevel 5000) [i386-solaris2.10] > > > > which was the current pre-release when I originally did the Puppet > > installs. I used that because the stable release broke Puppet in > > some other exciting way I can no longer recall... > > > > Matt > > > > -- > > * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * > > --- People can do the work, so machines have time to think --- > > > > > > > -- > * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * > --- People can do the work, so machines have time to think --- > > >-- * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * --- People can do the work, so machines have time to think --- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Feb 16, 2009, at 5:39 PM, Matt McLeod wrote:> > And nope, it doesn''t: > > Feb 17 04:29:03 wrath puppetd[20155]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 04:46:51 wrath puppetd[20449]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 06:26:32 wrath puppetd[21618]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 09:15:18 wrath puppetd[23987]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > > Does anyone actually use scheduling in Puppet? Hell, at this point, > is anyone other than me even reading this?/me kind of catches up on list mail... I''ve not seen this before, and I just verified that finding a schedule shouldn''t be at all related to the order in which resources get instantiated on the client or anything silly like that. This is just happening on a single node? I haven''t seen this before, but I have to admit that I don''t think schedules get used much, so this could be a long-running problem that no one''s run into. -- If you make people think they''re thinking, they''ll love you; But if you really make them think, they''ll hate you. -- Don Marquis --------------------------------------------------------------------- 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 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 -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> I''ve not seen this before, and I just verified that finding a schedule > shouldn''t be at all related to the order in which resources get > instantiated on the client or anything silly like that. > > This is just happening on a single node?It''s happened on the two nodes I''m testing with, but they''re both running the same Puppet+etc stack. I''ve just built a fresh stack for SPARC and am testing that at the moment. The problem has cropped up there yet but it''s only been running a few hours and it''s been intermittent on the first two nodes. I''ve just rolled out a much simpler test case: schedule {testsched: period=>daily, range=>"14 - 22", repeat=>1 } file{"/tmp/puppet-test.foo": ensure=>directory, schedule=>testsched } to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS) to see how that goes. It''d be just my luck that some oddity in our Sol10/x86 build environment tickles something in Ruby the wrong way... Will come back with more info tomorrow once it''s been running for 24 hours with the simplified test case. Matt -- * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ * --- People can do the work, so machines have time to think --- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I Have scheduling working quite well for many different OS''s.
I''m using something like that ina class inhertied by all machines.
class host-base::schedule {
# maintance schedule, run only once a day, between 2-4
schedule { maint:
range => "2 - 4",
period => daily,
repeat => 1
}
}
do you the define the schedule inside a class or a node definition?
cheers,
Ohad
On Tue, Feb 17, 2009 at 12:51 PM, Matt McLeod <matt@boggle.org> wrote:
>
> Luke Kanies wrote:
> > I''ve not seen this before, and I just verified that finding a
schedule
> > shouldn''t be at all related to the order in which resources
get
> > instantiated on the client or anything silly like that.
> >
> > This is just happening on a single node?
>
> It''s happened on the two nodes I''m testing with, but
they''re both
> running the same Puppet+etc stack.
>
> I''ve just built a fresh stack for SPARC and am testing that at the
> moment. The problem has cropped up there yet but it''s only been
> running a few hours and it''s been intermittent on the first two
nodes.
>
> I''ve just rolled out a much simpler test case:
>
> schedule {testsched:
> period=>daily,
> range=>"14 - 22",
> repeat=>1
> }
> file{"/tmp/puppet-test.foo":
> ensure=>directory,
> schedule=>testsched
> }
>
> to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
> to see how that goes. It''d be just my luck that some oddity in
our
> Sol10/x86 build environment tickles something in Ruby the wrong way...
>
> Will come back with more info tomorrow once it''s been running for
> 24 hours with the simplified test case.
>
> Matt
>
> --
> * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
> --- People can do the work, so machines have time to think ---
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
The one that''s failing is defined in a module which is included
by the node definition. It is, essentially:
schedule {blah: ...}
define {blahpkg: ..., schedule=>blah}
class blahclass {
blahpkg{somepackage}
}
in the module ''blahclass'' and then in the node defintion file:
node somenode inherits stuff {
include blahclass
}
So the schedule is defined outside the class, and is referred to
by the define called by the class, and all specified in the same
module''s init.pp.
I posted the full version earlier.
The simplified test-case which hasn''t failed yet but it''s only
been
a few hours is defined directly in the node definition. If that
works I''ll try moving it into a module and see what happens then.
Matt
Ohad Levy wrote:> I Have scheduling working quite well for many different OS''s.
>
> I''m using something like that ina class inhertied by all machines.
> class host-base::schedule {
> # maintance schedule, run only once a day, between 2-4
> schedule { maint:
> range => "2 - 4",
> period => daily,
> repeat => 1
> }
> }
>
> do you the define the schedule inside a class or a node definition?
>
> cheers,
> Ohad
>
> On Tue, Feb 17, 2009 at 12:51 PM, Matt McLeod <matt@boggle.org>
wrote:
>
> >
> > Luke Kanies wrote:
> > > I''ve not seen this before, and I just verified that
finding a schedule
> > > shouldn''t be at all related to the order in which
resources get
> > > instantiated on the client or anything silly like that.
> > >
> > > This is just happening on a single node?
> >
> > It''s happened on the two nodes I''m testing with, but
they''re both
> > running the same Puppet+etc stack.
> >
> > I''ve just built a fresh stack for SPARC and am testing that
at the
> > moment. The problem has cropped up there yet but it''s only
been
> > running a few hours and it''s been intermittent on the first
two nodes.
> >
> > I''ve just rolled out a much simpler test case:
> >
> > schedule {testsched:
> > period=>daily,
> > range=>"14 - 22",
> > repeat=>1
> > }
> > file{"/tmp/puppet-test.foo":
> > ensure=>directory,
> > schedule=>testsched
> > }
> >
> > to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
> > to see how that goes. It''d be just my luck that some oddity
in our
> > Sol10/x86 build environment tickles something in Ruby the wrong way...
> >
> > Will come back with more info tomorrow once it''s been running
for
> > 24 hours with the simplified test case.
> >
> > Matt
> >
> > --
> > * Matt McLeod | mail: matt@boggle.org | blog:
http://abortrephrase.com/ *
> > --- People can do the work, so machines have time to think ---
> >
> > >
> >
>
> >
--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
The greatly-simplified case works fine, or at least has done across
a couple of platforms for 24 hours.
A few hours ago I changed the proof-of-concept package management
version to place the schedule inside the class. i.e., rather than:
schedule{blah:}
define moreblah {..., schedule=>blah}
class theclass {moreblah{foo:}}
it''s now
define moreblah {..., schedule=>blah}
class theclass {
schedule{blah:}
moreblah{wibble:}
}
and it *seems* to be working. I can only assume that sometimes it
was parsing the class before the schedule, even though the schedule
was defined before the class in the same file in the manifest, but
now that the schedule is defined *in* the class the ordering is working
out OK.
But I''ll need to let it run for longer before I''m prepared to
say
it''s definitely OK.
Matt
Matt McLeod wrote:>
> Luke Kanies wrote:
> > I''ve not seen this before, and I just verified that finding a
schedule
> > shouldn''t be at all related to the order in which resources
get
> > instantiated on the client or anything silly like that.
> >
> > This is just happening on a single node?
>
> It''s happened on the two nodes I''m testing with, but
they''re both
> running the same Puppet+etc stack.
>
> I''ve just built a fresh stack for SPARC and am testing that at the
> moment. The problem has cropped up there yet but it''s only been
> running a few hours and it''s been intermittent on the first two
nodes.
>
> I''ve just rolled out a much simpler test case:
>
> schedule {testsched:
> period=>daily,
> range=>"14 - 22",
> repeat=>1
> }
> file{"/tmp/puppet-test.foo":
> ensure=>directory,
> schedule=>testsched
> }
>
> to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
> to see how that goes. It''d be just my luck that some oddity in
our
> Sol10/x86 build environment tickles something in Ruby the wrong way...
>
> Will come back with more info tomorrow once it''s been running for
> 24 hours with the simplified test case.
>
> Matt
>
> --
> * Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
> --- People can do the work, so machines have time to think ---
>
> >
--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
On Feb 17, 2009, at 8:53 PM, Matt McLeod wrote:> > The greatly-simplified case works fine, or at least has done across > a couple of platforms for 24 hours. > > A few hours ago I changed the proof-of-concept package management > version to place the schedule inside the class. i.e., rather than: > > schedule{blah:} > define moreblah {..., schedule=>blah} > class theclass {moreblah{foo:}} > > it''s now > > define moreblah {..., schedule=>blah} > class theclass { > schedule{blah:} > moreblah{wibble:} > } > > and it *seems* to be working. I can only assume that sometimes it > was parsing the class before the schedule, even though the schedule > was defined before the class in the same file in the manifest, but > now that the schedule is defined *in* the class the ordering is > working > out OK.I verified that parse order, and any other kind of order, couldn''t cause this problem - the schedule isn''t looked up until the whole catalog is instantiated. BTW, one relatively easy way to test on the hosts that are failing - look in the cached catalog yaml file and see if the schedule is actually in there. Because it sounds like you''re just not getting that schedule. -- Criminal: A person with predatory instincts who has not sufficient capital to form a corporation. --Howard Scott --------------------------------------------------------------------- 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 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 -~----------~----~----~----~------~----~------~--~---