migrations table
> look like? Here is an example of how to get a hold of that info:
> https://gist.github.com/kbarber/11196805
>
> ken.
>
>
> On Tue, Apr 22, 2014 at 11:10 PM, David Mesler
> >
> wrote:
> > I'm having an issue updating from 1.6.2.
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 KEY)
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
ome more help troubleshooting the output,
> head over to #puppet on IRC [3] and one 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://pro
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
> runn
t; DROP INDEX idx_catalog_resources_tags_gin;
>
> It is easily restored if it doesn't help ... but may take some time to
> build:
>
> CREATE INDEX idx_catalog_resources_tags_gin
> ON catalog_resources
> USING gin
> (tags COLLATE pg_catalog."default");
&g
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 thoug
end
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/daemo
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 real
where 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 upg
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
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
experience
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...
>
13 matches
Mail list logo
