Hi all,

I am experiencing a strange behavior on a plugin that I created. i
don't know if this is what I should expect, so maybe you can provide
me with some insights.

I want to have some stuff done in slurm_spank_task_init, but ONLY if
sbatch/srun was executed with "--myplugin". To do so, I created a
global variable "activate_plugin_var" in my myplugin.c, which is set
in an auxiliary function "set_ativate_plugin_var". This funcion is
registered as a spank_option, so when the user uses "--myplugin" it is
called and this global variable activate_plugin_var  gets a value.
Then, in slurm_spank_task_init, I check the value of the variable and
if it is set, then I do whatever.

So far this works fine. I don't know however if this is the most
elegant solution though. Probably the best idea would do whatever in
the auxiliary set_ativate_plugin_var function  instead of employing
this flag. The problem is that I want to access the values of the
spank_t object received in slurm_spank_task_init and with the
registered function you don't have them, so that's why I came with
this approach. The main problem I see is that the state is not saved
"forever", so the value of any global variable is not always what
you'd expect.   If there is any better solution, I am open to
suggestions.

The weird situation is however that this funcionality is affected by
"--export" flag.

- if I don't use the export, it works as expected.
- if I use export with "export=ALL", it is OK too.
- if I use export with "export=NONE" or "export=myVar=myValue", then:
-- set_ativate_plugin_var is called
-- slurm_spank_task_init is called
-- slurm_spank_task_init does NOT have activate_plugin_var with the
correct value.

This causes that my plugin does not detect that the user used the
flag, and it does nothing. I would say that this is an inconsistency,
as the behavior of the plugin should not depend on an unrelated flag.

Reading the manual I saw that with the "export" options that cause an
error in my plugin "the --get-user-env option will implicitly be set".
I thought that this might be the cause of the problem, but additional
tests on that flag proved me wrong. I am now a bit lost, so any help
would be welcome.

I guess my question would be,

- have you noticed a similar behavior? Is it expected, or in fact an
inconsistency?
- if you have coded a similar spank plugin, have you got any
suggestion for its architecture?
- have you got any solution to my problem, maybe through a different
approach or whatever?


thanks,


Manuel

Reply via email to