summaryrefslogtreecommitdiff
path: root/lib/oxidized/worker.rb
AgeCommit message (Collapse)Author
2017-02-10add one thread when requesting next via APISaku Ytti
2016-06-02cleaner specElvin Efendi
2016-06-02more debug stratementsElvin Efendi
2016-05-27Added feature to disable polling based on intervalAdam Winberg
2016-01-04Merge remote-tracking branch 'upstream/master' into merge-upstreamElvin Efendi
2015-12-27expose git repo name and commit oid in hook mechanism and environment variablesNick Hilliard
2015-12-13refactor and fix bugs introduced with new changesElvin Efendi
2015-11-13better test framework, more specs and Travis CIElvin Efendi
2015-08-28Initial implementation of the hook featureAnton Aksola
The current implementation is modular and allows users to define hooks in several ways: * Use one of the built-in hook types (currently only 'exec') * Define their own Hook classes inside ~/.config/oxidized/hook Exec hook type runs a user defined command with or without shell. It populates a bunch of environment variables with metadata. The command can either be run as synchronous or asynchronous. The default is synchronous.
2015-06-10add update for a node in log fileroot
2015-02-22refactor HOLB preventionSaku Ytti
Still not sure we want this. But previous one might have caused infinite loop in #work. Consider we have just 1 node all together, and our rotation interval is more than our MAX_INTER_JOB_GAP, then we'd add @want to 2, instead of 1. Now we want more threads than we have nodes, and 'while @jobs.size < @jobs.want' will never be true
2015-02-22Allow node to be removed while collectingSaku Ytti
Closes #68 (hopefully at least) Further, our TODO to refactor/redesign the code to move state from memory to disk should help.
2015-02-21Force new job if too long since last jobSaku Ytti
MAX_INTER_JOB_GAP is now 300s, if latest job was started 300s ago, we add new job. Ratioanele is that if we want n jobs, and all these jobs are taking very very long, or perhaps hanging, then we are blocking everything else too. Consider you have use one job, because it's enough to meet your rotation interval quota. Then some one box is somehow taking tens of minutes or hours, we won't figure out new amount of workers until it finishes, so we're blocking all other jobs from spawning. I'm not super happy about this solution, not really sure what is the right wayt to tackle it.
2014-07-11reset retry count on successSaku Ytti
2014-07-11add support for retrying failed attemptsSaku Ytti
Looks like this in syslog: Jul 11 21:05:53 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 22" Jul 11 21:05:53 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 23" Jul 11 21:05:54 ytti oxidized[9820]: 10.10.10.10 status no_connection, retry attempt 1 Jul 11 21:05:54 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 22" Jul 11 21:05:54 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 23" Jul 11 21:05:55 ytti oxidized[9820]: 10.10.10.10 status no_connection, retry attempt 2 Jul 11 21:05:55 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 22" Jul 11 21:05:55 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 23" Jul 11 21:05:56 ytti oxidized[9820]: 10.10.10.10 status no_connection, retry attempt 3 Jul 11 21:05:56 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 22" Jul 11 21:05:56 ytti oxidized[9820]: 10.10.10.10 raised Errno::ENETUNREACH with msg "Network is unreachable - connect(2) for "10.10.10.10" port 23" Jul 11 21:05:57 ytti oxidized[9820]: 10.10.10.10 status no_connection, retries exhausted, giving up
2014-05-07Add support for node stats0.0.57Saku Ytti
Bumpup gemspec
2014-03-13modified worker to work on a node only once per intervalAnton Aksola
2014-02-23Migrate to sinatra/puma from webrickSaku Ytti
As I can't do IO#select on sinatra/puma to run it when I have time, I have to run it on separate thread. This means Nodes container needs to be thread safe, it now has ghetto mutex locking, but I probably need to be be more focused what are the external methods that can be called and wrap those in @mutex.synchronize Provide also HTML UI not just JSON for ghetto UI to people who don't want to integrate
2013-04-21rename 'update' to 'store'Saku Ytti
'store' is more logical, as we cannot know if output method guarantees any version history which 'update' implies.
2013-04-20Example of Syslog triggered fetchSaku Ytti
'syslog.rb' listed to UDP port (or reads file). When IOS or JunOS style config change/commit message is seen, it triggers immediate update ot config It transports commit message (junos) remote host from which change was mde (ios) and who made the change (junos+ios). This is carried over to the 'output' methods, that is, 'git blame' will show IOS/JunOS user-name who made the change.
2013-04-17Initial commitSaku Ytti
Silly for shit-and-giggles attempt at rancid