[Puppet Users] Announce: puppet-agent 1.3.6 available

[Melissa Stone]

Puppet Agent 1.3.6 is now available! This is a security release that
updates OpenSSL to 1.0.2g, and addresses a number of recent CVEs.

See the release notes for the puppet agent package here:
http://docs.puppetlabs.com/puppet/latest/reference/release_notes_agent.html

To install or upgrade puppet-agent, follow the getting started directions:
http://docs.puppetlabs.com/puppet/latest/reference/index.html
-- 
Melissa Stone
Release Engineer, Puppet Labs
--

PuppetConf 2016 , October 17-21, San Diego,
California
*Early Birds save $350*

-
Register by June 30th

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAHEe_krbAZi9txuM4d0OBJnixwyLrQTnixD72OsnM1nQdJUd6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] directory environemnt doesn't seem to be working for vcsrepo

[Sans]

Hi there ,

I'm seeing a very strange error, which I cannot figure out where it's 
coming from:


*Error: Failed to apply catalog: Parameter revision failed on 
Vcsrepo[/var/www/wp007/wp-content]: Invalid value "". Valid values match 
/^\S+$/. at /usr/local/p19/puppet/modules/wordpress/manifests/app.pp:163*


Line #163  is where I specified the vcsrepo to do the git pull from staging 
branch. I cannot get any other info using -td or --trace. Any one has seen 
this error before or know what's going on?
Just to give you a but of background, the PuppetMaster is running with two 
environments: development and staging, with directory environment enabled. 
This error is coming from the staging instances.  Is it possible it's not 
getting the environment specific values to compile the catalog? Hoe do I do 
further debugging? 

Got really stuck in the middle, so nay help will be appreciated.

-San

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/13af960b-eaa6-4944-9800-b36a4ebb0e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] override class attributes

[TimV]

Hi -
I am trying to figure out how to best override
resource attributes for a module.  I know this might not
be the best way to do things, but it's where I am at currently.

In summary:

   - I have a module called Apache, that references the firewall class from 
   the puppetlabs/firewall module - to open ports 80/443.
   - I have a few nodes, that need wordpress installed (as well as apache) 
   - I need to override the default fw ports 80/443 being opened, for more 
   selective rules.

I am trying to override these resources similar to what is described here:
https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#overriding-resource-attributes

Here's my code:

nodes.pp
  node 'wordpress-dev.blah.example.com' {
include base
include users
include webteam
include apache
include libfw::wordpress
group { 'webteam':
  ensure  => present,
  name=> 'webteam',
  members => 'sdf, sdf1, sdf3, sdf4'
}
include basicfw
include lib-wordpress
include wordpress_cli
include php
}



Apache and wordpress are two very basic modules I wrote. 

apache::config
apache::config has the following:
class apache::config {
  firewall { '0050 allow http and https access':
chain  => 'LSO-Firewall-1-INPUT',
dport  => [80, 443],
proto  => tcp,
action => accept,
  }
}


Then in the wordpress module, I am trying to override this setting with:

lib-wordpress::config
class lib-wordpress::firewall inherits apache::config {
  Class['apache::config'] {
chain  => 'LSO-Firewall-1-INPUT',
dport  => [80, 443],
proto  => tcp,
action => reject,
  }
}

Puppet apply run's ok, but IPtables never changes.  The default rule 0050, 
stays as
accept. I also noticed with puppet-lint this warning:
class inherits across module namespaces



Is this because I am overriding a class that references another class 
(firewall)? If 
so, how should I avoid this? I might be running up against this bug:

> Note: If a base class declares other classes with the resource-like 
>> syntax, a class derived from it cannot override the class parameters of 
>> those inner classes. This is a known bug.
>>
>
Thank you.

Tim

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0d3b3462-4264-4411-af47-e1ded2db5797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: Puppet Enterprise 2015.3.3 is available

[Melissa Stone]

Dear Puppet Enterprise Users,

Puppet Enterprise 2015.3.3 is now available.

This is a security release of Puppet Enterprise. All users of Puppet
Enterprise 2015.x are encouraged to upgrade when possible to Puppet
Enterprise 2015.3.3.

Puppet Enterprise 2015.3.3 includes fixes to address a number of security
concerns. For more information on these vulnerabilities, please visit
https://puppetlabs.com/security. For information on the bug fixes in this
release, please see https://docs.puppetlabs.com/pe/2015.3/release_notes.html
.

As a current Puppet Enterprise user, you can upgrade to this new version as
part of your annual subscription. If upgrading, it is required to upgrade
your master, puppetdb and console servers first.

As always, we want to hear about your experiences with Puppet Enterprise.
If you have any questions about upgrading, be sure to get in touch with
Puppet Labs Support.
-- 
Melissa Stone
Release Engineer, Puppet Labs
--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAHEe_krp5asAX3VeOBPZP5V545kpjTjwxzFNKrgY%3D6PfHfwEdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Options for notifying external services in case of changing exported resources.

[Jelle Smet]

Hi list,


I have a Puppet module (internal to the company) which makes use of 
exported resources.
The exported resource data stored in PuppetDB is used to configure an 
external application.

I'm looking for a way to notify this external service in order to trigger 
it load the stored exported resources from PuppetDB.
If the "trigger" would be a log (syslog) event that would already be 
sufficient to work with.

I have found 3 ways to achieve this, but for different reasons I'm not 
allowed to use them:


   1. Use a Postgress trigger on the PuppetDB database which generates an 
   event in case data changes.
   
   2. https://github.com/ryanuber/puppet-tell.
   
   3. An exec of the "/usr/bin/logger" command with "*refreshonly*" which 
   subscribes to a a file resource writing the exported resources to a file.
   The data written to the file would then have to be the same as the 
   exported resources.
   This would mean, if the "exported resources"  change, the content of the 
   file changes which only then produce a syslog.

Unfortunately, the notify resource doesn't support "*refreshonly*".


Are there any other constructions which would allow me to notify an 
external application in case exported resources for a host have changed?


Thanks,

Jelle

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/76c5fe28-ee70-4a37-904f-2a883b8cdc60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Use apt.puppetlabs.com on Ubuntu xenial: no suitable hash entry in Release file

[Andreas Roth]

Hi,

i tried to use the apt.puppetlabs.com repo on xenial. Since there are not 
package for xenial yet i tried to use the package from Ubuntu wily instead, 
but i ran into this error:

W: Failed to fetch http://apt.puppetlabs.com/dists/wily/Release  No Hash 
entry in Release file 
/var/lib/apt/lists/partial/apt.puppetlabs.com_dists_wily_Release, 
which is considered strong enough for security purposes

I check the Release file and found the hash entries are wrong. apt (version 
1.2.4) looks for the Hash entries "SHA512", "SHA256", "SHA1", "MD5Sum" or 
"Checksum-FileSize", but the file in the repository provides "MD5Sum", 
"SHA1Sum", "SHA256Sum". I think is a some kind of spelling mistake. The 
section "SHA256Sum" should be "SHA256" without the "Sum" suffix (same for 
SHA1). 

I don't know what kind of changes are required to fix this, but i hope this 
can be fixed easily.

Andreas

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f281a08a-3b1d-423f-b816-6d5b1c494a76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB: Input to insert-facts-pv-pairs! does not match schema

[Wyatt Alt]

On 03/14/2016 06:34 AM, Akos Hencz wrote:

Hello,

We have a few nodes that fail to submit facts to PuppetDB, and the 
replace facts commands end up in the DLO. The exception is: 
clojure.lang.ExceptionInfo: Input to insert-facts-pv-pairs! does not 
match schema.
I suspect it is a problem with one of the facts, but I cannot 
determine which one. Looking at the output of 'facter -p' on any of 
the nodes seem to be fine.


I would like to ask for some advice on how to investigate the cause of 
this problem. :)


We run Puppet 3.8.4, PuppetDB 2.3.4, and PuppetServer 1.1.3. You can 
see the full exception text below.


Cheers,
Akos


clojure.lang.ExceptionInfo: Input to insert-facts-pv-pairs! does
not match schema: [nil (named (not (some (check %
a-clojure.lang.LazySeq) schemas)) pairs)] {:error [nil (named (not
(some (check % a-clojure.lang.LazySeq) schemas)) pairs)], :value
[44289 ([17 954] [90 58] [100 207518370] [147 137] [72 86] [96
274005961] [49 207518365] [31 57830745] [152 1307] [48 928] [104
295874761] [81 21735] [167 302087295] [162 167699] [68 25] [1 826]
[57 23] [119 291018089] [12 302087311] [7 912] [139 193] [134 539]
[205 28] [137 1299] [34 49] [18 200] [4 7644696] [14 7] [35
59021633] [1526 302087296] [58 73] [120 830] [163 65] [178 1293]
[80 870] [1527 302087294] [95 274005961] [40 157758900] [77
302087312] [116 101387066] [111 112] [41 57830745] [269911
302087303] [269910 193] [269912 57830745] [269909 57830745]
[269908 57830745] [269914 57830745] [269913 302087292] [195 65]
[1248 207518367] [2472 800] [2487 136] [2489 765] [2491 488] [2467
207518365] [2478 830] [2485 800] [2475 207518370] [2496 793] [2501
207518365] [2486 765] [2466 488] [93 302087302] [126 136] [23 105]
[15 50105231] [115 110] [136 299] [121 800] [129 57830729] [56
232889320] [56434 8543] [276 939] [70 75] [106 302087301] [98 229]
[110 57830742] [45 67] [24 883] [107 904] [124 182796497] [99 89]
[47985 302087314] [47983 81057077] [47982 223071] [47989 294247]
[47988 492094] [47991 82005831] [47987 228539865] [47986 81057081]
[47990 136333789] [47984 137976183] [49100 563] [49098 82071940]
[49093 136059519] [49095 108941256] [49116 82065378] [49114
82063765] [49118 82063767] [49117 82063764] [49121 82063916]
[49120 16973] [49115 63121] [49119 88397486] [49150 82064260] [66
302087301] [5 302087302] [63 31] [37 287849745] [51 25] [28
302087305] [73 3927] [485 28] [59 125] [13 302087310] [91 780] [54
94] [127 299] [11 765] [1528 488] [156 65] [215 28] [239
302087304] [21 295871169] [38 302087315] [25 882] [114 17] [101
57830743] [86 57830733] [39 302087308] [297092 195213941] [131
302087293] [130 802] [22 923] [1246 302087313] [2494 302087300]
[2462 68508392] [2473 57830743] [2457 3927] [67 1326] [133
302087305] [71 136778] [65 207518365] [2 169693143] [103 167718]
[19 763] [1529 302087289] [2461 28] [2453 302087302] [2500 200]
[2458 21735] [2493 302087302] [2477 295871174] [2464 200] [2492
539] [2459 8224991] [2476 167718] [2483 38] [2495 302087291] [2451
136778] [2460 91] [2488 17] [2454 67] [2469 112] [2463 302087305]
[2470 302087302] [141 1317] [88 302087297] [52 929] [1250 8224986]
[53 302087300] [123 46] [75 302087307] [135 57830744] [2246
302087298] [2471 302087309] [2455 539] [2452 302087302] [2465
188476291] [2484 188476291] [nil 302087288] [2497 1326] [2590
302087290] [2498 302087311] [33 25] [83 302087305] [79 87] [89 38]
[188 140] [69 169693143] [8 302087306] [122 13] [140 1283] [84 94]
[1249 295871170] [2479 295871169] [2525 295871169] [2474 59021633]
[2468 59021633] [164 65] [92 295871169] [456928 36] [6 1608] [248
302087299] [16 57830733] [1015 104292798] [174 236] [128
302087302] [20 68508392] [102 765] [113 793] [125 80] [26 765]
[118 101387069] [9 296645235] [30 290] [108 800] [76 302087302]
[183 44875635] [158 296658966] [1530 8224991] [278 938] [29
295871174] [10 91] [105 302087291] [27 302087302] [142 181]
[263862 302087287] [50 67] [196 167697] [1531 268074168] [2482
266778936] [2490 57830732] [2499 116471] [2481 929] [109 928] [43
2780] [146 65] [1532 31] [97 59021633] [36 67] [254 28] [3 1671]
[87 200] [62 802] [181 912] [191 1299] [74 904] [60 57830733] [44
302087297] [94 296930720] [85 59021638])], :schema
[#schema.core.One{:schema Int, :optional? false, :name factset-id}
#schema.core.One{:schema (either [[(one Int "path-id") (one Int
"value-id")]] #{[(one Int "path-id") (one Int "value-id")]}),
:optional? false, :name pairs}], :type :schema.core/error}


--
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 view this discussion on the web 

[Puppet Users] PuppetDB: Input to insert-facts-pv-pairs! does not match schema

[Akos Hencz]

Hello,

We have a few nodes that fail to submit facts to PuppetDB, and the replace 
facts commands end up in the DLO. The exception is: 
clojure.lang.ExceptionInfo: Input to insert-facts-pv-pairs! does not match 
schema.
I suspect it is a problem with one of the facts, but I cannot determine 
which one. Looking at the output of 'facter -p' on any of the nodes seem to 
be fine. 

I would like to ask for some advice on how to investigate the cause of this 
problem. :)

We run Puppet 3.8.4, PuppetDB 2.3.4, and PuppetServer 1.1.3. You can see 
the full exception text below.

Cheers,
Akos


clojure.lang.ExceptionInfo: Input to insert-facts-pv-pairs! does not match 
schema: [nil (named (not (some (check % a-clojure.lang.LazySeq) schemas)) 
pairs)] {:error [nil (named (not (some (check % a-clojure.lang.LazySeq) 
schemas)) pairs)], :value [44289 ([17 954] [90 58] [100 207518370] [147 
137] [72 86] [96 274005961] [49 207518365] [31 57830745] [152 1307] [48 
928] [104 295874761] [81 21735] [167 302087295] [162 167699] [68 25] [1 
826] [57 23] [119 291018089] [12 302087311] [7 912] [139 193] [134 539] 
[205 28] [137 1299] [34 49] [18 200] [4 7644696] [14 7] [35 59021633] [1526 
302087296] [58 73] [120 830] [163 65] [178 1293] [80 870] [1527 302087294] 
[95 274005961] [40 157758900] [77 302087312] [116 101387066] [111 112] [41 
57830745] [269911 302087303] [269910 193] [269912 57830745] [269909 
57830745] [269908 57830745] [269914 57830745] [269913 302087292] [195 65] 
[1248 207518367] [2472 800] [2487 136] [2489 765] [2491 488] [2467 
207518365] [2478 830] [2485 800] [2475 207518370] [2496 793] [2501 
207518365] [2486 765] [2466 488] [93 302087302] [126 136] [23 105] [15 
50105231] [115 110] [136 299] [121 800] [129 57830729] [56 232889320] 
[56434 8543] [276 939] [70 75] [106 302087301] [98 229] [110 57830742] [45 
67] [24 883] [107 904] [124 182796497] [99 89] [47985 302087314] [47983 
81057077] [47982 223071] [47989 294247] [47988 492094] [47991 82005831] 
[47987 228539865] [47986 81057081] [47990 136333789] [47984 137976183] 
[49100 563] [49098 82071940] [49093 136059519] [49095 108941256] [49116 
82065378] [49114 82063765] [49118 82063767] [49117 82063764] [49121 
82063916] [49120 16973] [49115 63121] [49119 88397486] [49150 82064260] [66 
302087301] [5 302087302] [63 31] [37 287849745] [51 25] [28 302087305] [73 
3927] [485 28] [59 125] [13 302087310] [91 780] [54 94] [127 299] [11 765] 
[1528 488] [156 65] [215 28] [239 302087304] [21 295871169] [38 302087315] 
[25 882] [114 17] [101 57830743] [86 57830733] [39 302087308] [297092 
195213941] [131 302087293] [130 802] [22 923] [1246 302087313] [2494 
302087300] [2462 68508392] [2473 57830743] [2457 3927] [67 1326] [133 
302087305] [71 136778] [65 207518365] [2 169693143] [103 167718] [19 763] 
[1529 302087289] [2461 28] [2453 302087302] [2500 200] [2458 21735] [2493 
302087302] [2477 295871174] [2464 200] [2492 539] [2459 8224991] [2476 
167718] [2483 38] [2495 302087291] [2451 136778] [2460 91] [2488 17] [2454 
67] [2469 112] [2463 302087305] [2470 302087302] [141 1317] [88 302087297] 
[52 929] [1250 8224986] [53 302087300] [123 46] [75 302087307] [135 
57830744] [2246 302087298] [2471 302087309] [2455 539] [2452 302087302] 
[2465 188476291] [2484 188476291] [nil 302087288] [2497 1326] [2590 
302087290] [2498 302087311] [33 25] [83 302087305] [79 87] [89 38] [188 
140] [69 169693143] [8 302087306] [122 13] [140 1283] [84 94] [1249 
295871170] [2479 295871169] [2525 295871169] [2474 59021633] [2468 
59021633] [164 65] [92 295871169] [456928 36] [6 1608] [248 302087299] [16 
57830733] [1015 104292798] [174 236] [128 302087302] [20 68508392] [102 
765] [113 793] [125 80] [26 765] [118 101387069] [9 296645235] [30 290] 
[108 800] [76 302087302] [183 44875635] [158 296658966] [1530 8224991] [278 
938] [29 295871174] [10 91] [105 302087291] [27 302087302] [142 181] 
[263862 302087287] [50 67] [196 167697] [1531 268074168] [2482 266778936] 
[2490 57830732] [2499 116471] [2481 929] [109 928] [43 2780] [146 65] [1532 
31] [97 59021633] [36 67] [254 28] [3 1671] [87 200] [62 802] [181 912] 
[191 1299] [74 904] [60 57830733] [44 302087297] [94 296930720] [85 
59021638])], :schema [#schema.core.One{:schema Int, :optional? false, :name 
factset-id} #schema.core.One{:schema (either [[(one Int "path-id") (one Int 
"value-id")]] #{[(one Int "path-id") (one Int "value-id")]}), :optional? 
false, :name pairs}], :type :schema.core/error}


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/046f28c4-867c-40ab-86c1-e09bef5d9a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet catalog compilation job queue idea

[SG Madurai]

Hi Pienaar, Thank you for noting that, will check this a little later - 
Direct Puppet does sound v interesting
(but as of now, we are on OSS so lets see)

On Wednesday, March 9, 2016 at 12:02:40 AM UTC+9, R.I. Pienaar wrote:
>
> I believe the thing thats happening here is called Direct Puppet, there 
> were some puppet conf talks about this you might want to look at the 
> videos. 
>
> But it's around reworking the compile flow so you can pre-compile things, 
> re-run 
> earlier compiled things, redo the static catalogs and even rewriting the 
> compiler 
> in C++ 
>
> There are stuff happening on Jira at the moment, but I'd guess lots of 
> this will 
> be PE only if recent blogs are anything to go by 
>
> - Original Message - 
> > From: "jcbollinger"  
> > To: "puppet-users"  
> > Sent: Tuesday, 8 March, 2016 15:51:31 
> > Subject: Re: [Puppet Users] Re: puppet catalog compilation job queue 
> idea 
>
> > On Monday, March 7, 2016 at 7:57:33 PM UTC-6, SG Madurai wrote: 
> >> 
> >> Hi John, Thank you for the update. 
> >> 
> >> Pardon me if i am asking about things that have been clarified/ settled 
> >> already. 
> >> 
> >> From what i understand, agent run times are primarily determined by 
> >> - catalog compilation time at master 
> >> - the time for agent to apply catalog on its node 
> >> 
> >> 
> > 
> > Both of those are contributors.  The former is rarely a major one. 
>  There 
> > is also time spent by the agent computing facts, which is usually even 
> > less, but can be costly if costly custom facts are installed. 
> > 
> > Also, catalog application often is not an agent-only activity, as it 
> > commonly involves the agent obtaining files from the master's file 
> server. 
> > This can be very expensive for both the agent and the master. 
> > 
> > 
> > 
> >> So was basically wondering if there is an option to separate these 2 
> >> functions and manage these 2 independent of each other (at times 
> convenient 
> >> for each of these activities) 
> >> 
> >> 
> > 
> > Nodes have as much control as they want to exercise of when and how 
> often 
> > they perform catalog runs.  If they run the agent in daemon mode then 
> they 
> > can configure the run interval, but they also have the option of running 
> it 
> > at the times they choose via a scheduler, such as cron, or on-demand 
> either 
> > manually or via a remote-control system such as MCollective. 
> > 
> > The master does perform some caching to speed catalog building, but as I 
> > already said, it is impractical for it to cache whole catalogs for 
> direct 
> > service to clients.  The problem here lies in determining accurately and 
> > efficiently when cached catalogs are stale. 
> > 
> > 
> > 
> >> If these concerns shouldn't arise with running multiple puppet masters 
> w/ 
> >> puppet db (or by imply upgrading...we are on v3.8 btw), then will 
> explore 
> >> that option first. 
> >> 
> > 
> > 
> > If your master(s) do not adequately serve the catalog request load, then 
> > the quickest solution is often to empower them by running more 
> puppetmatser 
> > threads, adding CPU, adding RAM, increasing network bandwidth, and/or 
> > shutting down other services.  "Shutting down other services" might 
> include 
> > moving PuppetDB to a separate machine.  Do also attend to the 
> possibility 
> > of uneven load: some kinds of site configurations lend themselves to 
> highly 
> > uneven load on the master, such that it sometimes gets transiently 
> > overloaded even though it has sufficient capacity for its average load. 
> > 
> > If individual catalog compilations are taking a long time, then it is 
> > probably worthwhile investigating why that is.  It may well be the case 
> > that you can realize substantial improvements by modifying your manifest 
> > set.  If the master is bogged down at the file server then you are 
> probably 
> > managing either large numbers of files or very large files, or both, in 
> an 
> > inefficient way; this is an area where it is relatively easy to shoot 
> > yourself in the foot. 
> > 
> > If none of those alternatives yield the catalog service bandwidth you 
> need, 
> > then the next logical step is multiple masters. 
> > 
> > 
> >> 
> >> I couldn't be sure if these configuration options (multiple puppet 
> masters 
> >> w/ puppet db) by itself can take care of the issues we are facing with 
> >> agent runs  in our environment 
> >> (timeouts, slowness..) 
> >> 
> >> We have one puppet master (v3.8) managing 150-200 nodes in an 
> environment. 
> >> 
> > 
> > 
> > That's a fairly substantial load for a single master, but whether it's 
> at 
> > or beyond the capacity you should expect depends greatly on your 
> manifests, 
> > data, and nodes. 
> > 
> > In any event, you started off in the wrong direction by asking about 
> agent 
> > run times.  If agents' catalog requests are being serviced slowly, and 
> > especially if they