On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum <luke.bi...@fasthosts.co.uk> wrote: > I've seen the same issue as well. I just tested then, adding a simple > notify resource to a node and it took three consecutive runs of > puppetd before the message appeared:
Is it the number of runs or is it simply time based? > > # puppetd --test > info: Retrieving plugin > info: Caching catalog for puppet-master-01 > info: Applying configuration version '1289376693' > notice: Finished catalog run in 30.24 seconds > # puppetd --test > info: Retrieving plugin > info: Caching catalog for puppet-master-01 > info: Applying configuration version '1289377768' > notice: Finished catalog run in 24.98 seconds > # puppetd --test > info: Retrieving plugin > info: Caching catalog for puppet-master-01 > info: Applying configuration version '1289379786' > notice: foo > notice: /Stage[main]//Node[puppet-master-01]/Notify[test]/message: > defined 'message' as 'foo' > notice: Finished catalog run in 26.46 seconds > > > # /opt/ruby-enterprise/bin/gem list > > *** LOCAL GEMS *** > > facter (1.5.8) > fastthread (1.0.7) > mysql (2.8.1) > passenger (2.2.9) > puppet (2.6.2) > rack (1.1.0) > rake (0.8.7) > > > On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com> wrote: >> I am having the same issue, and am running about the same stack. >> >> CentOS 5.5 >> >> facter (1.5.8) >> fastthread (1.0.7) >> passenger (2.2.15) >> puppet (2.6.2) >> puppet-module (0.3.0) >> rack (1.1.0) >> rake (0.8.7) >> stomp (1.1.6) >> >> On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com> wrote: >> > Patrick, thanks for the speedy reply once again. >> >> > I'm using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0. >> >> > From what I've read in this group and in Puppet Labs docs/wikis, >> > Debian/Ubuntu users do seem to have an easier time generally than >> > CentOS/Red Hat :-\ >> >> > Can I pass my command-line options to Puppetmasterd in the config.ru >> > file? >> >> > -Kent >> >> > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote: >> > > On Nov 9, 2010, at 9:34 AM, Kent wrote: >> >> > > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote: >> > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote: >> >> > > >>> Hi all, >> >> > > >>> I'm a new puppet user and new to the forum. >> >> > > >>> I just switched my Puppetmaster to running inside Apache (via >> > > >>> Passenger). When I make a change to a resource on the master, it >> > > >>> sometimes takes a given node TWO runs before the master will realize >> > > >>> the resource has changed and recompile a new catalog version for the >> > > >>> node. For example, say my puppetmaster is serving configuration >> > > >>> version '123' to a node. I change the file permissions for a file >> > > >>> resource that's part of that catalog and then do a puppet run on the >> > > >>> node. If I'm running with Passenger, the master serves config version >> > > >>> '123' one more time (the agent makes no changes). The next time I run >> > > >>> the node's agent, the master compiles new catalog version '456' and >> > > >>> the agent makes the permission change. >> >> > > >>> A few items of note: >> >> > > >>> 1. This is not a problem with all changes to puppet module content. >> > > >>> For example, if I change the source contents of a file in the 'files' >> > > >>> directory of a module, the master will notice this immediately and >> > the >> > > >>> puppet agent on the node will grab the new file on the first run >> > > >>> following the change on the master. >> >> > > >> Fact: >> > > >> Files sent using "source" aren't part of the catalog. Instead, the >> > client asks the server for them while the client is using the catalog and >> > not during the compilation done on the server. >> >> > > >> Speculation: >> > > >> I would guess this is because the problem you are having is happening >> > during the compilation on the server. >> >> > > >>> 2. At first I thought maybe this was a timing issue (e.g. I was >> > doing >> > > >>> the puppet run too quickly after making the resource change) but it's >> > > >>> not; whether I wait 5 seconds or 5 minutes before making the first >> > > >>> puppet run, the master still doesn't notice the change. I set the >> > > >>> 'filetimeout' setting in /etc/puppet/puppet.conf to 0 and it didn't >> > > >>> help. >> >> > > >>> Any ideas on what's going on here? (thanks in advance for your help) >> >> > > > Ahh, Ok, that makes sense. The source files are not part of the >> > > > manifests, just pointed to by them. >> >> > > > However, I am still having a problem with changed manifests not >> > > > getting "noticed" by the Puppetmaster until the second run after it's >> > > > been changed. This is only a problem when running puppetmaster as a >> > > > rack app inside Apache. Of course, if I restart Apache it will serve >> > > > up the most recent manifests on the first puppet run that connects to >> > > > it, but it would be irritating to have to restart httpd every time I >> > > > want to make a change to a module/manifest. >> >> > > > I also tried setting the puppet.conf option 'ignorecache = true' to no >> > > > avail. (side note: on the "servertype" option in puppet.conf, official >> > > > documentation still states that the only valid modes are 'webrick' and >> > > > 'mongrel'. What is the appropriate mode for running with passenger?) >> >> > > My puppetmaster is working fine and that option isn't set which means >> > it's defaulting to webrick. >> >> > > > Final note: The puppetmaster always logs that it has compiled a >> > > > catalog and expired the cached one, even on the first runs where the >> > > > new manifest does not yet take effect. (and annoyingly, puppetmaster >> > > > under passenger now logs to /var/log/messages instead of /var/log/ >> > > > puppet/puppetmaster.log; >> >> > > I don't know how to fix this, but this doesn't happen under Ubuntu. >> >> > > > it seems puppetmaster as a rack application >> > > > does not look at /etc/sysconfig/puppetmaster - so I can't add options >> > > > like verbosity, etc.) >> >> > > Correct. Files in /etc/sysconfig are red when a service starts. When >> > using passenger, the service is apache and puppetmaster is one of it's >> > subprocesses. >> >> > > The equivalent file is config.ru. It's in the folder you specify in the >> > apache config file. Just do a "find / -name config.ru". >> >> > > That said, you really shouldn't need to change it if puppetmaster is >> > managing to startup at all. >> >> > > > To me, it seems like there needs to be better Puppet Labs >> > > > documentation on the differences between running Puppetmaster >> > > > "normally" (e.g. with /etc/init.d/puppetmaster) versus as a Rack >> > > > application. >> >> > > What distro are you using? >> >> > > What version of puppet are you using? (puppet --version) >> >> > > How did you install puppet? >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-us...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> >> > . >> > For more options, visit this group at >> >http://groups.google.com/group/puppet-users?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- Nigel Kersten - Puppet Labs - http://www.puppetlabs.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
