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 <[email protected]> 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 > [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
