Yes, I agree with you, but to get to a solutions, please read my two
paragraphs below ...
Best regards,
Kern
On 08/16/2018 04:28 PM, Phil Stracchino wrote:
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.)
------------------------------------------------------------------------------
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
