View Issue Details

IDProjectCategoryView StatusLast Update
0001164bareos-coredirectorpublic2023-11-02 10:54
Reporterjoergs Assigned Tobruno-at-bareos  
PrioritylowSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version19.2.4~rc1 
Summary0001164: Inheritance of JobDefs is handled oddly
DescriptionJobs can retrieve settings from JobDefs. A JobDefs itself can also retrieve settings from JobDefs.
So, specifying a job via

1. job
2. job -> jobdef
3. job -> jobdef -> jobdef
all works as expected.

However, specifying
job -> jobdef -> jobdef -> jobdef
does not work.
Additional Informationhttps://github.com/joergsteffens/bareos/tree/dev/joergs/master/systemtests-jobdefs-runscripts
does implement a systemtest for part iof this behavior. Handling RunScripts fom JobDefs is a special, even more complicated case.
TagsNo tags attached.

Activities

stephand

stephand

2019-12-20 10:36

developer   ~0003709

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."
(See https://docs.bareos.org/Configuration/Director.html#jobdefs-resource)

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.
joergs

joergs

2019-12-20 12:34

developer   ~0003711

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.
embareossed

embareossed

2019-12-22 23:13

reporter   ~0003714

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.
bruno-at-bareos

bruno-at-bareos

2023-09-05 16:58

manager   ~0005386

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.
bruno-at-bareos

bruno-at-bareos

2023-11-02 10:54

manager   ~0005491

Documentation updated to state the case of runscript being added and not replaced
https://github.com/bareos/bareos/pull/1581

Issue History

Date Modified Username Field Change
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
2023-11-02 10:54 bruno-at-bareos Status feedback => closed
2023-11-02 10:54 bruno-at-bareos Resolution open => fixed
2023-11-02 10:54 bruno-at-bareos Note Added: 0005491