Hi Kent, On Mon, Nov 15, 2010 at 8:05 AM, Kent <kentmshu...@gmail.com> wrote:
> Nigel, > > It is number-of-runs based. If I execute two runs in rapid succession > 2 seconds after changing a manifest on the puppetmaster, the new > config *will* be pushed on the second run. On the other hand I can > walk away for 10 minutes and when I then execute the runs, the new > config will still not take effect until the second run. > > Is it likely this has something to do with catalog caching on the > master? I tried turning caching off by setting 'ignorecache = true' in > puppet.conf this is a client side configuration, it probably won't help. but this didn't help, so maybe this isn't the issue here. > try setting filetimeout=0 on the puppet master for more information you can: man puppet.conf > -Kent > > On Nov 14, 8:18 am, Nigel Kersten <ni...@puppetlabs.com> wrote: > > 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> > <puppet-users%2bunsubscr...@google groups.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<puppet-users%2bunsubscr...@googlegroups.com> > . > > > For more options, visit this group athttp:// > 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<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.
