On 8/16/18 10:12 AM, Kern Sibbald wrote: > Hello, > > The overrides, in my view, are a big mess with overrides and other > places where values can take precedence. > The problem is that it is such a big mess that changing anything is > likely to break someone's backups. If someone (not me) is willing to go > through the code and document all the different places that a particular > variable can be set, and then fixes *all* of them so that they are > reported in the Job log, and makes sure that anything entered via > bconsole takes precedence - then I would be happy to accept the patch. > Please note carefully, a big piece of the work is modifying the manual, > so this needs to be done as well for this to be accepted. > > If someone wants to do a smaller manageable project, then simply > reporting at each place where a directive takes precedence over another > one in a different resource would already be a big help. At least the > user could then know why a variable is not what he expected.
As far as I'm aware, all the behavioral overrides in the resources work as expected and as documented, in scheduled jobs. Job overrides JobDefs, Full/Incremental/Differential Backup Pool override Pool, just like the manual says. That's not the problem. The problem is that when the Full/Incremental/Differential Backup Pool directives are used in JobDefs to set specific target pools for specific Job levels, and the administrator runs a manual job from the console, the Full/Incremental/Differential Backup Pool directives silently override the target pool chosen in the console by the administrator. Any parameter set by the administrator should always override anything in any resource. Because not only should the administrator be assumed to know what he or she is doing and have chosen that parameter for a reason, but sometimes the administrator may want to test a set of parameters that the administrator knows *should not* work, expressly to verify that they do not work. (For a hypothetical example, to verify that volumes from pool X *cannot* be mounted to storage Y which is not allowed to use that Pool.) -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
