Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
vladimir-mencl-eresearch opened this issue Apr 17, 2012 · 3 comments
Open

Comments

@vladimir-mencl-eresearch
Copy link
Member

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
Copy link
Member Author

Hi,

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

  • Template specifies the variable name plus permitted values, user gets a listbox, the selection gets passed as an environment variable
  • Template specifies the variable name, user gets to type in a value, the value entered gets passed as an environment variable
  • Advanced: user types in a variable name + value (possibly multiple variables - but all single-valued)

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 makkus closed this as completed in 3550ef6 Jun 26, 2012
@makkus makkus reopened this Jun 26, 2012
@makkus
Copy link

makkus commented Jun 26, 2012

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
Copy link
Member Author

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

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

No branches or pull requests

2 participants