Bareos Bug Tracker
Bareos Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000886bareos-core[All Projects] directorpublic2017-12-27 09:142018-01-03 03:35
Reporterbozonius 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusfeedbackResolutionreopened 
PlatformLinuxOSUbuntuOS Version14.04
Product Version16.2.4 
Target VersionFixed in Version 
Summary0000886: "Run Before Job" in JobDefs is run even though a backup job specifies a different "Run Before Job"
DescriptionMy JobDefs file specifies a script that is to be run before a backup job. This is valid for nearly all of my jobs. However, one backup job should not run that script; instead, I want to run a different script before running that backup. So in that one specific backup job definition, I override the default from JobDefs with a different script. But the JobDefs script still gets run anyway.
Steps To ReproduceCreate a JobDefs with a "Run Before Job" set to run "script1."

Create one or more jobs (e.g., maybe "job-general1," "job-general2," "job-general3") for the general case, not setting "Run Before Job" in those, allowing the setting to default to the one specified in JobDefs (i.e., "script1").

Create one job for a specific case ("job-special"), setting "Run Before Job" to "script2."

Run any of the general case jobs ("job-general1," etc.) and "script1" is correctly run, since no override is specified for any of those jobs.

Run "job-special" and BOTH script1 AND script2 are run before the job.
Additional InformationFrom the documentation, section 9.3, "Only the changes from the defaults need to be mentioned in each Job." (http://doc.bareos.org/master/html/bareos-manual-main-reference.html#QQ2-1-216 [^]) I infer that the description of Bareos's defaulting mechanism fits the industry-standard definition of the term "default."

Please note that this was also an issue in Bacula, and one of the (many) reasons I chose to move on to Bareos. I was told by Bacula support that I did not understand the meaning of "default," which actually, I really am sure I do. I've worked with software for over 30 years, and the documented semantics (as per section 9.3) seem to comport with general agreement about the meaning of default mechanisms. To this day, I do not think I've ever seen a single exception to the generally agreed-upon meaning of "default." Even overloading mechanisms in OO languages all appear to comport to this intention and implementation.

I hope this will not result in the same stonewalling of this issue and that this bug, while minor for the most part but potential for disaster for those unawares in other more complicated contexts, can and will be fixed in some upcoming release. Thanks.
TagsNo tags attached.
bareos-master: impact
bareos-master: action
bareos-18.2: impact
bareos-18.2: action
bareos-17.2: impact
bareos-17.2: action
bareos-16.2: impact
bareos-16.2: action
bareos-15.2: impact
bareos-15.2: action
bareos-14.2: impact
bareos-14.2: action
bareos-13.2: impact
bareos-13.2: action
bareos-12.4: impact
bareos-12.4: action
Attached Files

- Relationships

-  Notes
(0002845)
joergs (administrator)
2017-12-27 12:59

The "Run Before Job" directive can be specified multiple times in a resource to run multiple run scripts. So the behavior you describe is to be expected. You can extend a DefaultJob with additional run scripts.

To achieve the behavior requested by you, you might use the fact, that DefaultJobs can be used recursively.

JobDefs {
  Name = "defaultjob-without-script"
  ...
}

JobDefs {
  Name = "defaultjob-with-script"
  JobDefs = "defaultjob-without-script"
  Run Before Job = "echo 'test'"
}

Jobs can than either refer to "defaultjob-with-script" or "defaultjob-without-script".
(0002848)
bozonius (reporter)
2017-12-27 21:30

How is this reflected in the documentation? I was kind of wondering if one could specify multiple JobDefs (default configurations), which would be handy. However, the documentation, as I read it, does not seem to encourage the reader to consider multiple JobDefs, as you have illustrated.

Thank you for this information, and I will DEFINITELY make use of this facility -- actually, it addresses precisely what I wanted! However, it might be a good idea to add something to the JobDefs documentation to illustrate exactly what you have shown here. Thanks.

I wonder, even had a bareos admin read every last word of the documentation, if this approach to handling job defaults would be obvious to them. This is not a criticism of the current docs; as docs go, this is one of the more complete I've seen. It's just that sometimes it takes more explanation of various options than those one might glean by reading the material quite literally as I have. I also don't believe that one will necessarily read every last bit of the documentation in the first place (though you might be within your right to claim every user really should have in order to leverage the full advantage of this extensive system). Users may be tasked with correcting or adding an urgent matter and not have time to read everything, rather heading straight to the portion of the docs seeming to be most relevant for the task at hand.

In the opening paragraph of JobDefs might be a good place to add this information. It is the place where it would be most likely NOT to be missed. Again, thanks for the info.
(0002853)
joergs (administrator)
2018-01-02 16:39

Already documented at http://doc.bareos.org/master/html/bareos-manual-main-reference.html#directiveDirJobJob%20Defs [^] :

To structure the configuration even more, Job Defs themselves can also refer to other Job Defs.

If you know a better way to describe this: also patches to the documentation are always welcome.
(0002856)
bozonius (reporter)
2018-01-03 03:35

From the doc:

Any value that you explicitly define in the current Job resource, will override any defaults specified in the Job Defs resource.

That isn't quite exactly correct. What really happens is something a bit more akin to subclassing I think, albeit these "classes" are linear; there is no "multiple inheritance," so to speak (though THAT might even be useful?).

BareOS JobDefs values are not always replaced; they may be replaced, or appended instead. Appending in this manner is not typical of the way we normally speak of defaults in most of the software kingdom (at least in my own experience).

Not sure how to improve the docs, but just thought I'd put this out there: This notion of single parent subclassing. Perhaps this could lead us toward a better description.

- Issue History
Date Modified Username Field Change
2017-12-27 09:14 bozonius New Issue
2017-12-27 12:59 joergs Note Added: 0002845
2017-12-27 12:59 joergs Status new => feedback
2017-12-27 21:30 bozonius Note Added: 0002848
2017-12-27 21:30 bozonius Status feedback => new
2018-01-02 16:39 joergs Note Added: 0002853
2018-01-02 16:39 joergs Status new => resolved
2018-01-02 16:39 joergs Resolution open => no change required
2018-01-02 16:39 joergs Assigned To => frank
2018-01-02 16:53 frank Assigned To frank =>
2018-01-03 03:35 bozonius Note Added: 0002856
2018-01-03 03:35 bozonius Status resolved => feedback
2018-01-03 03:35 bozonius Resolution no change required => reopened


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker