Are we even sure this is a PuppetDB problem? And not an issue with the Dashboard itself? As I've shown, the report gets stored in PuppetDB as a failure. Having said that, if there is an issue in the summary of the report we don't store those stats ourselves in PuppetDB.
Maxim, I'd do the test I provided in my gist, that is - the curl request against PuppetDB to confirm this is true for PuppetDB at least. For 2.1.0 and above this should work fine. At the very least we need to determine where this fault is. It sounds like PUP-283, but the latest version of Puppet Board shouldn't suffer this issue since its not querying against the Dashboard, but PuppetDB directly. ken. On Mon, Jul 21, 2014 at 5:31 PM, José Luis Ledesma <joseluis.lede...@gmail.com> wrote: > Which version of puppedb are you running? If I'm not wrong, from puppetdb > 2.1 catalog compilation errors are stored , but not for previous versions. > > Regards, > > El 21/07/2014 17:17, "Maxim Nikolaev" <m...@maximnik.com> escribió: > >> No. I haven't this feature. >> my puppet.conf looks like this: >> >> [main] >> modules = /etc/puppet/modules >> hiera_config = /etc/puppet/hiera.yaml >> pluginsync = true >> server = HOSTNAME >> #port = 8081 >> >> [agent] >> server = HOSTNAME >> report = true >> classfile = $vardir/classes.txt >> localconfig = $vardir/localconfig >> >> [master] >> certname = HOSTNAME >> dns_alt_names = HOSTNAME >> autosign = true >> reports = store, http, puppetdb, tagmail >> reporturl = http://HOSTNAME/reports/upload >> hiera_config = /etc/puppet/hiera.yaml >> storeconfigs = true >> storeconfigs_backend = puppetdb >> >> I found discussion about this bug: >> >> http://projects.theforeman.org/issues/3851 >> >> But I want to know if there is any workaround. >> >> If catalog fails on client side - I can see error reports. >> >> On Monday, July 21, 2014 4:01:43 PM UTC+3, Ken Barber wrote: >>> >>> Hi Maxim, >>> >>> This is not directly reproducible by myself today: >>> https://gist.github.com/kbarber/c6941099bea07096361e ... >>> >>> Perhaps something in your puppet.conf is doing this, I could imagine >>> something like: >>> >>> usecacheonfailure = true >>> >>> Causing this to happen, but I can't reproduce the exact same conditions >>> myself. >>> >>> Here is my basic puppet.conf fwiw: >>> >>> # cat /etc/puppet/puppet.conf >>> [main] >>> logdir=/var/log/puppet >>> vardir=/var/lib/puppet >>> ssldir=/var/lib/puppet/ssl >>> rundir=/var/run/puppet >>> factpath=$vardir/lib/facter >>> >>> [agent] >>> report = true >>> >>> [master] >>> ssl_client_header = SSL_CLIENT_S_DN >>> ssl_client_verify_header = SSL_CLIENT_VERIFY >>> storeconfigs = true >>> storeconfigs_backend = puppetdb >>> reports = store,puppetdb >>> trusted_node_data = true >>> >>> Perhaps you can share your so we can see what settings may be causing it. >>> >>> ken. >>> >>> On Mon, Jul 21, 2014 at 12:55 PM, Maxim Nikolaev <m...@maximnik.com> >>> wrote: >>> > Hi >>> > >>> > I'm using Puppet with Dashboard and PuppetDB and Puppetdb board. I can >>> > see >>> > all nodes and rfeports. >>> > Problem is that when puppet fail to run on instance - i get report >>> > "unchanged" instead of "fail". >>> > >>> > For ex. I've changed postfix manifest to install package postfix1. >>> > Puppet >>> > failed to run: >>> > >>> > Error: Could not retrieve catalog from remote server: Error 400 on >>> > SERVER: >>> > Invalid relationship: File[/etc/postfix/main.cf] { require => >>> > Package[postfix] }, because Package[postfix] doesn't seem to be in the >>> > catalog >>> > But I got unchanged report instead of failed also in dashboard and in >>> > puppetdb. >>> > >>> > Puppet: 3.6.2 >>> > Facter: 2.1.0 >>> > OS: Amazon Linux >>> > >>> > -- >>> > 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...@googlegroups.com. >>> > To view this discussion on the web visit >>> > >>> > https://groups.google.com/d/msgid/puppet-users/29057799-8d81-4272-b02d-8df2f8ba38f7%40googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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/f9cde2d1-0d85-49ec-a5bd-2582dd01ff16%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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/CAF_B3dcBY5T5sEisZrK%3DgyF9woaZiCqdT_hw5zFxDCCUyAr1yQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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/CAE4bNTnU6YffqzkZxxk%3DX8AAW8_z7XiUHORc%3DWnu8N4T4eJNRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
