On Thursday, January 24, 2013 2:41:53 PM UTC, jcbollinger wrote: > > On Thursday, January 24, 2013 5:24:58 AM UTC-6, Daniel wrote: >> >> Seems that chaining exported resources might not be too efficient and >> produces lots of data that could be the reason for puppetdb crashing. >> >> The culprits being these two lines in two manifest files: >> >> ./nsca/server.pp: #File <<| tag == $get_tag |>> -> Nagios_host <<| tag == >> $get_tag |>> >> ./nrpe/server.pp: #File <<| tag == $get_tag |>> -> Nagios_host <<| tag == >> $get_tag |>> >> >> > > And there may be your combinatorial problem. Supposing that the tags are > not specific to the exporting node, the numbers of Files and Nagios_hosts > increase linearly with the number of nodes, but the number of relationships > among them increases with the square of the number of nodes. > Do you in fact need the order of application constraints that the chaining > declared? All of them? >
I don't need all of them. The reason I added it was to fix problems with files not being created when puppet tried to realize services, etc., thus producing an incorrect nagios setup. It worked in my small environment and only gave me a pause after days of trying to figure out what the hell is going on in the larger one. Looks like I didn't understand implications of this configuration, but to be honest I haven't found much in terms of documentation on chaining exported resources, potential implications and problems. Now I know, so "I've learnt something today" :). One suggestion - I would have a "WFT?" moment a lot sooner if --summarize displayed a number of relationships generated by my crazy config. I don't know if it's possible/easy to implement, but may be worth having a look at. Depending on what relationships you actually need, you have various options: > > 1) If it doesn't actually matter whether Puppet syncs given Files before > or after it syncs any particular Nagios_host, then you never needed any > relationships at all, and simply removing the chaining as you did is the > best solution. > As stated above, I've added it after failures, so I do need some sort of relationships. 2) If specific Files must be synced before specific Nagios_hosts, then you > should express those relationships and not any others. In particular, if > you only need relationships among Files and Nagios_hosts exported by the > same node, then you should declare the relationships on the exporting side > instead of on the collecting side. (And if they always come in such pairs > then perhaps you should wrap then in a defined type and export that > instead). > That's the most likely approach I'm going to implement in the "next iteration" of this module. 3) If you really need something along the lines that the chaining expressed > -- all Files with a given tag synced before all Nagios_hosts bearing that > tag -- then you can break the combinatorial problem by introducing an > artificial barrier resource for each tag: > I most likely don't need this, but will have it in mind for future experiments with exported resources. Thanks for your comprehensive answer. Regards, Daniel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
