grisu / grisu-template

Grisu template client
2 stars 1 forks source link

Feature request: widget to add ENV key/value pairs #5

Open vladimir-mencl-eresearch opened 12 years ago

vladimir-mencl-eresearch commented 12 years ago

Hi,

It would be really useful to have a widget that allows to specify job environment variables as key value pairs, same as what

add env key value does in GriCli

This would be quite useful with LoadLeveler - there is a number of options for how the LoadLeveler job gets submitted that can be specified in environment variables (GBLL_*).

E.g., to set unlimited blocking (tasks can be arbitrarily scattered across free slots on compute nodes), one would submit the job with (RSL-level): (environment=(GBLL_BLOCKING unlimited))

It would be a "nice to have" for "ordinary" LL jobs, but would really help with jobs submitted to the BlueGene - some choices to be made can only be expressed in these variables. It would be possible to submit BG/P jobs without this. But this would be useful to e.g. specify the BG/P mode (SMP/DUAL/VirtualNode) via an env variable.

vladimir-mencl-eresearch commented 12 years ago

Hi,

Just a clarification: for the widget to be useful, it would be useful to support the following use cases:

Basically, the same set of widgets (except for file selector) that can be used for constructing the list of arguments would be useful for constructing the list of environment variables.

Many thanks in advance!

Cheers, Vlad

makkus commented 12 years ago

Ups, didn't see your 2nd post. So, for now, only the "advanced" usecase is implemented. Specify like that:

[env] type = EnvironmentVariablePanel size = 800x250

For the other ones, would you be able to come up with a usecase so I can understand what you mean?

Also, could that be done with additional config options for existing widgets? If so, could you prepare an example template that provides the input fields and tell me how the vars are created. I could use that as a starting point.

vladimir-mencl-eresearch commented 12 years ago

Hi Markus,

Thanks for the work on this. I just got to test this.

The EnvironmentVariablePanel is looking great and would be a great solution for the Advanced use case (3). However, when I tried using it, it did not seem to pass the values entered into the job description that got submitted. Was this already supposed to be working?

One example for that is GBLL_BLOCKING=unlimited, which would get interpreted by loadleveler.pm as the LL "# @ blocking = unlimited" option.

Regarding the simpler use cases (1) and (2), I have just added into grisu-templates a template that would demonstrate this: GenericLLExt (Generic template with LoadLeveler extensions).

The BG_MODE, BG_CONNECT and GBLL_BLOCKING widgets should translate into environment variables passed in the job description.

I can imagine this could be done either by: (1) marking these widgets as producing environment variables instead of command-line arguments: isEnvironment = true (2) Adding a global environment property that would collect the information from the widgets in a similar way as the command-line property does (except that command-line property is a single string (well, list of words) while the environment would be a list of key-value pairs). Something like either: environment = GBLL_BLOCKING=${GBLL_BLOCKING} BG_CONNECT=${BG_CONNECT} BG_MODE=${BG_MODE} or allowing a per-environment variable syntax:

environment.GBLL_BLOCKING=${GBLL_BLOCKING}
environment.BG_MODE=${BG_MODE}
environment.BG_CONNECT=${BG_CONNECT}

perhaps with a list of variables: environment.variables=BG_CONNECT,BG_MODE,GBLL_BLOCKING

I think you'll now get what I mean - not sure which of these would be reasonably easy to implement.

I the end, the values must go into the job description environment list.

Thanks for the effort you are putting into it.

Cheers, Vlad