View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001164||bareos-core||director||public||2019-12-19 17:19||2023-09-05 16:58|
|Summary||0001164: Inheritance of JobDefs is handled oddly|
|Description||Jobs can retrieve settings from JobDefs. A JobDefs itself can also retrieve settings from JobDefs.|
So, specifying a job via
2. job -> jobdef
3. job -> jobdef -> jobdef
all works as expected.
job -> jobdef -> jobdef -> jobdef
does not work.
does implement a systemtest for part iof this behavior. Handling RunScripts fom JobDefs is a special, even more complicated case.
|Tags||No tags attached.|
I really doubt that this makes sense, I also dare to say that the possibility to use inheritance or nesting of JobDefs should be considered a bug, as the documentation already quite clearly defines:
"The JobDefs resource permits all the same directives that can appear in a Job resource. However, a JobDefs resource does not create a Job, rather it can be referenced within a Job to provide defaults for that Job. This permits you to concisely define several nearly identical Jobs, each one referencing a JobDefs resource which contains the defaults. Only the changes from the defaults need to be mentioned in each Job."
In this respect inheritance of JobDefs was obviously never intended. Allowing arbitrary levels of inheritance/nesting of JobDefs could allow inscrutable configurations and problems would be hard to reproduce. The first sentence in the documentation should be clarified and instead say:
"The JobDefs resource permits all the same directives that can appear in a Job resource, except JobDefs. JobDefs can not be nested."
When really considering to allow nesting JobDefs, there must be a defined maximum nesting depth. In any case it would also require to detect bad configurations like JobDefs referencing each other or indirect circular referencing.
Also the handling of RunScript in JobDefs is rather odd, as it deviates from the expected behaviour of beeing able to override parameters from JobDef in a Job.
That is not easily to decide.
The documentation clearly states in https://docs.bareos.org/master/Configuration/Director.html#config-Dir_Job_JobDefs :
"To structure the configuration even more, Job Defs themselves can also refer to other Job Defs."
So it is a documented behavior.
Also the code tries to handle it. However, it handles it incorrectly (only one level of inheritance inside JobDefs) .
I did not care about JobDefs in the past, but I know at least 4 installations using JobDef inheritance, also one pull request and at least one other Mantis ticket refer to this behavior.
Jobs and JobDefs can contain multiple RunScripts and RunScripts can have different parameter: RunBefore vs. RunAfter, RunOnClient vs RunOnHost, ...
Should a RunScript directive in a Job really overwrite all RunScript directive from a JobDef, even if they are of different types?
In my opinion, it would be handled clearer if inherited RunScripts are added, at it is now.
However, I really agree, that this must be obvious for the user. Currently, the ConfigParser already stores information, about if a directive is inherited. This could be extended, that the ConfigParser also stores from which jobDef a setting is inherited. Currently, the console command "show Jobs verbose" already gives some more insight about job definitions. This could also be extended in a way that the verbose mode of show command shows also where a directive is defined. Both should be relatively easy to implement. Also the JobLog could state, where a RunScript is defined.
If there is a decision against inherited JobDefs, I strongly opt for not changing this behavior in the next major release, but mark it as deprecated and remove it in the major release there after.
|I note that in this discussion, no mention of multiple inheritance has been mentioned. If we are going for featureness, it might be something to consider.|
Can we state on documented sentence has to be deprecated and removed as soon as possible.
After 4 years, the test branch didn't exist anymore, nor code effort will be made to fix/improve the behavior.
Will be closed within 7 days.
|2019-12-19 17:19||joergs||New Issue|
|2019-12-19 17:20||joergs||Status||new => acknowledged|
|2019-12-20 10:36||stephand||Note Added: 0003709|
|2019-12-20 12:34||joergs||Note Added: 0003711|
|2019-12-22 23:13||embareossed||Note Added: 0003714|
|2023-09-05 16:58||bruno-at-bareos||Assigned To||=> bruno-at-bareos|
|2023-09-05 16:58||bruno-at-bareos||Status||acknowledged => feedback|
|2023-09-05 16:58||bruno-at-bareos||Note Added: 0005386|