 |
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". |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
I tried the link in your note https://bugs.bareos.org/view.php?id=886#c2853, but it takes me to the start of the doc, not the specific section, which is what I think your link is supposed to do. Seems like a lot of links (and anchors) in the doc are broken this way. References to the bareos doc from websites (like linuxquestions) are now broken; I realize there might not be much that can be done about external references outside of bareos.org. |
|
|
A lot of stabilization in terms of links has be done in documentation since then (Including how to contribute, by proposing a PR for a change). For example actual 22x version. https://docs.bareos.org/bareos-22/Configuration/Director.html#jobdefs-resource Question, would you like to propose a change? |
|
|
Documentation updated for 23 and backported to 22 |
- Anonymous
