Bugzilla – Bug 1179
modules-config: order dependency and side effects should be documented or managed
Last modified: 2016-12-16 16:44:45 CET
There seems to be some confusion generated from the documentation:
module-config: <"module names">
Module configuration, a list of module names separated by spaces, surround the string with quotes (""). The modules can be validator, iterator... [DNS64] [PYTHON] ...The ordering of the modules is important.
All module options should be in this doc' section, and either of the following:
(1) Document what happens if the modules are listed in some order or another.
(2) Have the option parser correct the order, if there is only one right way.
unbound-checkconf already does this, it checks that the order (and which modules) is an allowed configuration.
Many of the modules are compile time options, not sure how to document them. Most would want to have their own documentation section. And most want to be listed at a specific position.
Best regards, Wouter
unbound-checkconf is okay, but for robustness the program using the options should just work. That is from the best I can tell, (some) modules might only work in one strict order. Therefore at conf read, treat the list as order agnostic, and then, rearrange them internally to that one strict order.
I could be wrong, and there may be desirable side effects from the order. That should be documented. Better yet, proper flag options implemented to control that side effect, and again we return to the module list is order agnostic.
Yes the module conf load order sure is a difficult option, where you need to know what the correct string is. The load order does have important effects, like, for python modules, the placement impacts what the python module can do and not do, if the python module sees the replies out of the iterator or out of the validator.
So, apart from documentation, I wouldn't want to do it. How about documentation suggests a couple of alternatives, you can select from this string or this string? i.e "iterator" , "validator iterator" , "python validator iterator" But then maybe with explanation what that does (i.e. enable validation, enable python plugin at one position where it sees validated results).
Best regards, Wouter
If the module option really is that flexible, then I guess thats' the best compromise. Then might I make one more suggestion. Depending on the selected debug level, print to the log file or syslog what the module order just did. Similarly for unbound-checkconf, express the side effects of the order even if they wouldn't generate error cases.