Skip to content

dird: fix RunScript parsing#358

Merged
joergsteffens merged 2 commits intobareos:masterfrom
joergsteffens:dev/joergs/master/runscript-fix
Dec 12, 2019
Merged

dird: fix RunScript parsing#358
joergsteffens merged 2 commits intobareos:masterfrom
joergsteffens:dev/joergs/master/runscript-fix

Conversation

@joergsteffens
Copy link
Member

This commit fixes a bug introduced during the recent months.
Without this patch, all RunScripts are configured to "Runs On Client = Yes".
Because of this, Admin and Console RunScripts did not work and are silently ignored.

With this change, RunScripts can by set to run locally or on the Client (Runs On Client = Yes/No).

A systemtest for this is included in PR #314 .

@franku
Copy link
Contributor

franku commented Dec 3, 2019

I cannot see why or where there is a bug introduced. The comment in the source that mentions the behaviour "Run on client by default" and the according line of code is present at least since the Bareos 12.4.1 release. This is what your PR changes.

Since we handle long established default behaviour very seriously, I do not recommend to merge your PR.

However, thanks for your contribution. What we should do next is:

  • please come to our developer meeting
  • tell why you think this is a bug and exactly when it was introduced
  • if we agree this is a bug we're going to fix it

@joergsteffens
Copy link
Member Author

Well, nevertheless it is a bug. I see, that you don't approve it, but why closing this PR already?
In the past, the line if (res_runscript->target.empty()) have been if (!res_runscript->target) and target have been a pointer, not a std::string. So there have been a difference between nullprt, emty string ("") or string with content. Also I've added a systemtest to check this behavior in PR #314, to verify this behavior.

@joergsteffens joergsteffens reopened this Dec 3, 2019
@joergsteffens joergsteffens force-pushed the dev/joergs/master/runscript-fix branch from 54123a4 to 93f1a2b Compare December 6, 2019 13:21
@joergsteffens
Copy link
Member Author

As discussed: rebased on master, add systemtest.

Copy link
Contributor

@franku franku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bug you discovered was caused by the former "tri-state" of the "target" value that previously could be nullptr, empty string or a string.

Nowadays the target value is not a char* (using POOLMEM*) but a std::string, thus the nullptr value is impossible. The problem appears because the empty string is actually a valid setting, whereas the std::string::empty() function is used to check if the string can be overwritten by a default value.

As far as I understood your solution sets the default value every configparser pass but allows the default string to be "overwritten" by a empty string.

IMHO the buggy behaviour won't affect users because almost most of them use the "run on client=yes" default setting. However, we should fix this.

I tried to run the python-bareos-test on my laptop but it fails. So we need to figure out why. I will come with a PN to your email and then we can discuss that. Therefore I chose "Request Changes".

This commit fixes a bug introduced during the recent months.
Without this patch, all RunScripts are configured to "Runs On Client = Yes".
Because of this, Admin and Console RunScripts did not work and are silently ignored.

With this change, RunScripts can by set to run locally or on the Client (Runs On Client = Yes/No).
Add test class PythonBareosJsonRunScriptTest
to check if RunScripts are executed in the correct context.
@joergsteffens joergsteffens force-pushed the dev/joergs/master/runscript-fix branch from 93f1a2b to 720b0a3 Compare December 12, 2019 12:31
@joergsteffens
Copy link
Member Author

Implemented the requested changes and rebased on master.

@joergsteffens joergsteffens merged commit b2f656e into bareos:master Dec 12, 2019
@joergsteffens joergsteffens deleted the dev/joergs/master/runscript-fix branch December 12, 2019 12:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants