Puppet users - Sep 2013 - puppetlabs/puppetdb module when using passenger for master

I''m working on configuring a master in a lab environment, using Puppet
Open
Source.  My master is running RHEL 6.

I want to use modules to manage the master itself as much as possible, so I 
can use puppet to bootstrap itself as I go forward and move into production.

Using puppetlabs/puppetdb to configure puppetdb, I''ve overcome most of
my
issues but I have two questions.

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....

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".....

Thanks!

# cat manifests/master-config.pp
include epel
class { ''puppetdb'':
        listen_address => ''puppet.example.com'',
        open_listen_port => true,
}
class { ''puppetdb::master::config'': }

selboolean { "httpd_can_network_connect":
        persistent => true,
        value => on,
}

# puppet apply master-config.pp
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults
Error: Could not start Service[puppetmaster]: Execution of
''/sbin/service
puppet master start'' returned 1:
Error: /Stage[main]/Puppetdb::Master::Config/Service[puppetmaster]/ensure: 
change from stopped to running failed: Could not start 
Service[puppetmaster]: Execution of ''/sbin/service puppetmaster
start''
returned 1:

-- 
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+unsubscribe@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.

> 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 the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@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.

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 <ken@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+unsubscribe@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+unsubscribe@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.