Configuration file

This is the default configuration file for plugin template: switch

```ini

GENERAL SECTION

(plugin metadatas)

[general]

Notes about the name of the plugin:

- the name of the plugin is given by the content of .layerapi2_label

in this directory (format: plugin_{name of the plugin}@mfdata)

- the old "name" key in this file is not used anymore

Version of the plugin (X.Y.Z)

If the value is {{MFMODULE_VERSION}},

the current module version is used

_version={{MFMODULE_VERSION}}

Release of the plugin

_release=1

Summary (one line) of the goal of the plugin

_summary=one line summary about your plugin

License of the plugin

_license=Proprietary

URL of the plugin homepage

_url=http://yourpluginhomepage

Name of the maintainer of the plugin on the form "Firstname FAMILYNAME "

_maintainer=Firstname FAMILYNAME

Vendor of the plugin

_vendor=MetWork

STEP SECTIONS

(one section [step_xxxxx] for each step)

You can have several blocks [step_xxxx] if your plugin

contains several steps.

If you have only one step in your plugin, please use "main" as your

step name in [step_xxxxx]. So just one [step_name] section in this case.

[step_main]

Command (and args) to be executed

Notes :

- null means no command to execute

- this command can be launched several times (see workers/numprocesses)

- the command must pop redis queue {{MFDATA_CURRENT_STEP_QUEUE}}

(dynamically generated), so it must include {MFDATA_CURRENT_STEP_QUEUE} in its args

You can use following placeholders :

- {{MFDATA_CURRENT_PLUGIN_NAME}}: replaced by the plugin name

- {{MFDATA_CURRENT_PLUGIN_DIR}}: replaced by the plugin

directory fullpath.

- {MFDATA_CURRENT_STEP_NAME}: replaced by the step name

- {MFDATA_CURRENT_STEP_QUEUE}: replaced by the name of the queue

for the plugin/step on redis

- {MFDATA_CURRENT_STEP_DIR}: replaced by the step directory

- {CUSTOM_...}: replaced by the corresponding configuration value under

the [custom] section of this file (example: {CUSTOM_FOO} will be

replaced by the value of the configuration key "foo" under [custom]

section.

- {{ENV_VAR}}: replaced by the corresponding env var.

- {STANDARD_STEP_ARGUMENTS}: replaced by various but standard arguments

for every step (must be always here at the end)

- it's not the command called for each incoming file, it's a daemon implemented

with Acquisition framework in Python; if you want to execute a binary command

for each incoming file, please bootstrap a "fork" plugin

_cmd_and_args=switch_step --rules-file={CUSTOM_RULES_FILE} --no-match-policy={{MFDATA_INTERNAL_PLUGINS_SWITCH_NO_MATCH_POLICY}} {STANDARD_STEP_ARGUMENTS}

Failure policy : keep (default), delete or move

failure_policy = keep

Destination directory when failure_policy is move (mandatory in this case)

(if failure_policy != move, this configuration key is not used)

must be something like: plugin_name/step_name

failure_policy_move_dest_dir =

If set then the process will be restarted sometime after max_age and

max_age + random(0, max_age) seconds.

0 => disable this feature

max_age = 3600

Split stdout/stderr logs into different files?

AUTO => the global conf MFDATA_LOG_TRY_TO_SPLIT_STDOUT_STDERR is used

(default: don't split)

1 => split

0 => don't split

log_split_stdout_stderr=AUTO

Split logs of multiple workers into different log files?

AUTO => the global conf MFDATA_LOG_TRY_TO_SPLIT_MULTIPLE_WORKERS is used

(default: don't split)

1 => split

0 => don't split

log_split_multiple_workers=AUTO

The number of processes to run for this step

note: you can use {{MFHARDWARE_NUMBER_OF_CPU_CORES_MULTIPLIED_BY_2}} value

to avoid a kind of hardware automatic value (see "env |grep HARDWARE" as mfdata

to find other automatic values)

numprocesses = 1

if you set debug=1, numprocesses will be forced to 1

and we will try to set all debug options and features

(max_age will also be forced to 0 and mflog minimal level will be set to DEBUG)

DON'T USE IT ON PRODUCTION!!!

debug=0

The number of seconds to wait for a step to terminate gracefully

before killing it. When stopping a process, we first send it a TERM signal.

A step may catch this signal to perform clean up operations before exiting.

If the worker is still active after {timeout} seconds, we send it a

KILL signal. It is not possible to catch a KILL signal, so the worker will stop.

If you use the standard Acquisition framework to implement your step, the

TERM signal is handled like this: "we don't process files anymore but we

try to end with the current processed file before stopping". So the

timeout must by greater than the maximum processing time of one file.

(must be set and >0)

timeout=600

!!! ADVANCED SETTINGS !!!

Coma separated list of watched directories (relative to MFDATA_DATA_IN_DIR)

You should keep {MFDATA_CURRENT_STEP_DIR} here unless you know exactly

what you are doing.

If several plugins watch the same directory, they will compete to process

files. If you want to copy files to multiple plugins, use a copy or a

switch plugin.

This parameter can be useful only if you don't want to use

default guess_file_type and switch plugins (advanced use)

watched_directories={MFDATA_CURRENT_STEP_DIR}

resource limit for each step process

rlimit_as => maximum area (in bytes) of address space which may be taken

by the process.

rlimit_nofile => maximum number of open file descriptors for the current

process.

rlimit_stack => maximum size (in bytes) of the call stack for the current

process.

This only affects the stack of the main thread in a multi-threaded process.

rlimit_fsize => maximum size of a file which the process may create.

(empty value means no limit)

rlimit_as = 1000000000 rlimit_nofile = 1000 rlimit_stack = 10000000 rlimit_fsize = 10000000000

[custom]

rules_file

rules_file={{MFMODULE_RUNTIME_HOME}}/tmp/config_auto/plugin_{{MFDATA_CURRENT_PLUGIN_NAME}}_rules.ini

```