pt-stalk plugins can't access the real --prefix

Reported by Fernando Ipar on 2012-11-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit
Low
Brian Fraser

Bug Description

When writing plugins that will collect additional data, it would be useful to have access to the prefix used for current collections.

If the user does not specify --prefix, right now the $prefix is created local and therefore unavailable to plugins:

         if [ "$OPT_COLLECT" ]; then
            local prefix="${OPT_PREFIX:-$(date +%F-%T | tr ':-' '_')}"

Daniel Nichter (daniel-nichter) wrote :

Brian pointed out that local in Bash is like local in Perl, so a plugin does have access to $prefix, but the tool should really update OPT_PREFIX with its default value so plugins can use that.

summary: - $prefix not available for pt-stalk plugins
+ pt-stalk plugins can't access the real --prefix
tags: added: plugin pt-stalk
Changed in percona-toolkit:
status: New → Confirmed
tags: added: plugins
removed: plugin
Changed in percona-toolkit:
milestone: none → 2.2.2
Changed in percona-toolkit:
importance: Undecided → Low
assignee: nobody → Daniel Nichter (daniel-nichter)
Brian Fraser (fraserbn) on 2013-04-03
Changed in percona-toolkit:
assignee: Daniel Nichter (daniel-nichter) → Brian Fraser (fraserbn)
Brian Fraser (fraserbn) on 2013-04-03
Changed in percona-toolkit:
status: Confirmed → Invalid
Daniel Nichter (daniel-nichter) wrote :

[1:04pm] Daniel: re not changing OPT_*, why save and restore OPT_PREFIX ^ ?
[1:05pm] brian: Daniel: That way the "default" behavior for OPT_PREFIX ggets called on every iteration
[1:05pm] brian: date +%F-%T | tr ':-' '_'
[1:05pm] brian: ^that being the default
[1:06pm] brian: So if you don't restore it, every iteration will have the same prefix, which is not the current behavior.
[1:06pm] brian: Perhaps I should add a test for that?
[1:07pm] Daniel: brian: i think the fix is just:
[1:07pm] Daniel: - local prefix="${OPT_PREFIX:-$(date +%F-%T | tr ':-' '_')}"
[1:07pm] Daniel: er wait
[1:07pm] • Daniel looks at the option again
[1:09pm] Daniel: hm it's weird because the default is not constant
[1:09pm] Daniel: but a specified --prefix would be constant
[1:09pm] brian: (you can't do local OPT_PREFIX=... because local in bash has function scope, unlike Perl)
[1:10pm] Daniel: well, i guess the default is contant too: the string that is the cmd that runs date
[1:11pm] Daniel: brian: i think perhaps providing OPT_PREFIX to the plugin would confuse things...
[1:11pm] Daniel: we say "don't change OPT_ values" which kind of implies that we (i.e. the tool) doesn't change them either...
[1:12pm] Daniel: so OPT_whatever is guaranteed to be whatever --whatever actually was...
[1:13pm] Daniel: in the case of --prefix, it would make OPT_prefix different each time, or not if --prefix was specified
[1:13pm] Daniel: therefore, i think plugins should use $prefix, which is "shorthand" for either default --prefix or the specified --prefix
[1:14pm] Daniel: this way we don't bastardize how OPT_ act or should be treated.
[1:14pm] Daniel: what do you think?
[1:15pm] brian: Agreed. Mark the bug as invalid, but commit a patch pointing out that the current prefix is in $prefix?
[1:15pm] Daniel: yes

Daniel Nichter (daniel-nichter) wrote :

Brian: is there a branch or patch for this?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers