I'm having an issue updating from 1.6.2.
2014-04-22 17:00:33,043 INFO [main] [cli.services] PuppetDB version 1.6.3
2014-04-22 17:00:33,124 ERROR [main] [scf.migrate] Caught SQLException
during migration
java.sql.BatchUpdateException: Batch entry 0 CREATE TABLE certnames (name
TEXT PRIMARY
Currently I use the common import nodes/* method. With that I've always
had to restart the puppet master processes in order to process new node
files. Will that still be necessary with the new manifest directory
behavior?
--
You received this message because you are subscribed to the Google
of the PuppetDB folks can help you
out.
1 - https://projects.puppetlabs.com/issues/22977
2 - https://docs.puppetlabs.com/puppetdb/1.5/api/query/v3/catalogs.html
3 - http://projects.puppetlabs.com/projects/1/wiki/Irc_Channel
On Tue, Oct 29, 2013 at 11:50 AM, David Mesler
david
Resource duplication is 98.7%, catalog duplication is 1.5%.
On Tuesday, October 29, 2013 9:06:37 AM UTC-4, Ken Barber wrote:
Hmm.
I reconfigured postgres based on the recommendations from pgtune and
your
document. I still had a lot of agent timeouts and eventually after
running
to
build:
CREATE INDEX idx_catalog_resources_tags_gin
ON catalog_resources
USING gin
(tags COLLATE pg_catalog.default);
ken.
On Thu, Oct 24, 2013 at 4:55 PM, David Mesler
david@gmail.comjavascript:
wrote:
Hello, I'm currently trying to deploy puppetdb to my environment
Hello, I'm currently trying to deploy puppetdb to my environment but I'm
having difficulties and am unsure on how to proceed.
I have 1300+ nodes checking in at 15 minute intervals (3.7 million
resources in the population). The load is spread across 6 puppet masters. I
requisitioned what I
On Thursday, December 20, 2012 4:09:09 PM UTC-5, David Mesler wrote:
I’ve added some debugging messages to run_event_loop and figured out what
was going on. I’m going to reference line numbers in
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/daemon.rb to
make it easier on me
is backwards. It should be “next_agent_run +=
new_run_interval – agent_run_interval”.
On Tuesday, December 18, 2012 7:00:42 PM UTC-5, David Mesler wrote:
I've noticed when I strace a puppet agent that has failed to run after its
900 second runinterval, it's blocking on a really long select call. Like
that long select call comes from.
On Friday, December 14, 2012 3:15:25 PM UTC-5, David Mesler wrote:
I've recently upgraded from 2.6.9 to 3.0.1 and have noticed an oddity. Our
puppet agents are configured with a runinterval of 900 and a splaylimit of
450. Since upgrading I've noticed
I've recently upgraded from 2.6.9 to 3.0.1 and have noticed an oddity. Our
puppet agents are configured with a runinterval of 900 and a splaylimit of
450. Since upgrading I've noticed that once or twice a day our puppet
agents simply won't run for about an hour or so. Has anyone else
Do they ever wake up on their own? I just posted about my issue where every
once in a while my agents will sleep for an hour even though they're
configured to run every 15 (+ 7.5 splay) minutes.
--david
On Wednesday, December 12, 2012 5:50:00 PM UTC-5, MasterPO wrote:
I have 39 RHEL nodes
Julia, did you ever figure this out? I'm running into this issue as well.
--david
On Tuesday, May 22, 2012 5:28:05 AM UTC-4, Julia Smith wrote:
I'm trying to use the firewall resource and it works fine for me for
iptables.
However, I'm not sure how I purge ip6tables?
doing...
12 matches
Mail list logo
