Yes, I did set the max-threads count manually. I'm pretty green, and I'm under a fairly aggressive schedule, so I'm not very likely to file a patch soon, but maybe once I get through the next two months.....I expect not to be so green by then :-). In the meantime I will work out a workaround. I only have 6 production masters to deploy so even manual intervention will work but I figure I'll play with delivering the file etc. before I go that route.
On the master service, that should help. I will try the first suggestion and if it doesn't work I'll go with the second and make sure my documentation has good warnings about watching it during upgrades. I really appreciate the pointers, thank you! Pete On Fri, Sep 6, 2013 at 3:49 PM, Ken Barber <k...@puppetlabs.com> wrote: >> 1) I had to set max-threads higher than my CPU count in >> /etc/puppetdb/conf.d/jetty.ini before I could get jetty to behave well. I >> haven't yet determined if there is a way through the puppetdb module to >> manage this directly--I plan to dig on that, but if someone knows off the >> top of their heads I'd like to know.... > > From a PuppetDB perspective, we already have a fix for this: > http://projects.puppetlabs.com/issues/22168 ... just awaiting the next > release of 1.3.x/1.4.x. > > The gist of the change is that we will no longer allow settings that > 'break' Jetty 7, and will just raise the setting to an acceptable > level and warn the user instead. The 'bug' doesn't exist in Jetty 9, > so it should go away when we eventually get around to upgrading that. > > As far as the module, we don't support it directly as you can see: > https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/manifests/server/jetty_ini.pp > ... I presume you fixed this for yourself by adding an ini_setting. > I'm less impressed with this mechanism today, and in the future I want > to rewrite this implementation so settings aren't so 'static' - that > way we won't fall behind. Either way, feel free to raise a bug on the > fact we don't manage such a setting, or for bonus points raise a > patch. > > Bugs for the module are here: > https://github.com/puppetlabs/puppetlabs-puppetdb/issues > >> 2) less likely for me to find in the docs, and no luck googling so far--when >> puppetdb modules are applied, they attempt to restart puppetmaster. But >> since the puppet master is actually running out of passenger/apache, the >> restart needs to be service httpd restart, not service puppetmaster restart, >> and the puppetmaster service restart fails. Is there a way to tell the >> module that I'm using passenger and should restart httpd instead? Should I >> just link /etc/init.d/puppetmaster to /etc/init.d/httpd? That seems like an >> obvious solution, but I'm not sure if it's "right"..... > > So if you have 'httpd' managed elsewhere, ie: > > service { 'httpd': > ensure => running, > enabled => true, > hasstatus => true, > } > > You can just use: > > class { 'puppetdb::master::config': > puppet_service_name => 'httpd' > } > > Although I'm wary of parse order being a problem here: > https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/manifests/master/config.pp#L145-L149 > > So ... if the above doesn't work for you try: > > class { 'puppetdb::master::config': > restart_puppet => false, > } > Class['puppetdb::master::puppetdb_conf'] ~> Service['httpd'] > > Which is nasty (and I'm warning you now it will probably break at a > random point in the future, since it taps internals), but replicates > the internals without trying to conditionally declare service { > 'httpd': }. *sigh*. > > ken. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/uYUs9warywk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
