135/netdisco
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update docs

Browse Source
This commit is contained in:
Oliver Gorwits
2014-08-10 14:13:00 +01:00
parent 517b1ae4c1
commit 44b50f413f
3 changed files with 19 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
Netdisco/lib/App/Netdisco/Manual/Configuration.pod
View File

@@ -879,15 +879,14 @@ or remove any entries.
Value: Settings Tree. Default:
workers:
interactives: 2
pollers: 10
sleep_time: 2
pollers: 'AUTO * 2'
sleep_time: 1
Control the activity of the backend daemon with this configuration setting.
C<interactives> and C<pollers> sets how many workers are started for
interactive jobs (port control) and polling jobs (discover, macsuck, arpnip)
on this node, respectively. Other nodes can have different settings.
C<pollers> sets how many workers are started for interactive jobs (port
control) and polling jobs (discover, macsuck, arpnip) on this node. Other
nodes can have different settings. "C<AUTO>" is the number of CPU cores.
C<sleep_time> is the number of seconds between polling the database to find
new jobs. This is a balance between responsiveness and database load.

28
Netdisco/lib/App/Netdisco/Manual/Developing.pod
View File

@@ -54,9 +54,6 @@ For the daemon, it's very similar:
DBIC_TRACE=1 ~/bin/localenv bin/netdisco-daemon-fg
Don't be alarmed by the high rate of database queries in the daemon - most of
them are communicating only with a local in-memory SQLite database.
Happy hacking!
=head1 Introduction
@@ -418,24 +415,12 @@ the central Netdisco database and booking out jobs which it's able to service
according to the local configuration settings. Jobs are "locked" in the
central queue and then copied to a local job queue within the daemon.
Along with the Manager we start zero or more of two other types of worker.
Some jobs such as port control are "interactive" and the user typically wants
quick feedback on the results. Others such as polling are background tasks
which can take more time and are less schedule sensitive. So as not to starve
the "interactive" jobs of workers we have two types of worker.
The Interactive worker picks jobs from the local job queue relating to device
and port reconfiguration only. It submits results directly back to the central
Netdisco database. The Poller worker similarly picks job from the local queue,
this time relating to device discovery and polling.
There is support in the daemon for the workers to pick more than one job at a
time from the local queue, in case we decide this is worth doing. However the
Manager won't ever book out more jobs from the central Netdisco job queue than
it has workers available (so as not to hog jobs for itself against other
daemons on other servers). The user is free to configure the number of
Interactive and Poller workers in their C<config.yml> file (zero or more of
each).
workers in their C<config.yml> file (zero or more).
The fourth kind of worker is called the Scheduler and takes care of adding
discover, macsuck, arpnip, and nbtstat jobs to the queue (which are in turn
@@ -458,17 +443,6 @@ Configuration for SNMP::Info comes from the YAML files, of course. This means
that our C<mibhome> and C<mibdirs> settings are now in YAML format. In
particular, the C<mibdirs> list is a real list within the configuration.
=head2 DBIx::Class Layer
The local job queue for each Job Daemon is actually an SQLite database running
in memory. This makes the queue management code a little more elegant. The
schema for this is of course DBIx::Class using Dancer connection management,
and lives in L<App::Netdisco::Daemon::DB>.
There is currently only one table, the port control job queue, in
L<App::Netdisco::Daemon::DB::Result::Admin>. It's likely this name will change
in the future.
=head1 Other Noteable Technology
=head2 C<local::lib>