Dynamic updates of Welcome message on login

[ndjones]

Provide a mechanism for the login message to be dynamically updated with contextual information specific to the user.

[makkus]

You mean for gricli login after ssh login?

[ndjones]

Yep currently it just tells me which backend i've logged into. perhaps its not shell scripts required, tho it might be combination, of shell scripts for local environment, and internal scripts for providing updates on current jobs running, etc. Ideally would be scripted, so updatable and customisable, without requiring release of code

[makkus]

Ah, ok. Should be easy enough to implement.

How should gricli know which script to run? Environment variable, if that exists, do it, else, don't? Or have a fixed path that gricli looks up and if the script exists, run it?

[ndjones]

i always preferred env vars myself..

[makkus]

Yeah, I think that's the way to go.

Actually, we could probably combine it with #71, if we implement that, this is just a matter of checking for the environment variable and call the new command using the path to the script...

[ndjones]

ok, have pushed this to August milestone, to align with #71

[makkus]

Implemented rudimentary exec command and check for environment variable "GRICLI_LOGIN_SCRIPT". If that one exists and points to an executable file, it will be run after a successful login...

No idea what exactly we want to display here, so I'll leave this ticket open until somebody wrote a script that we actually call...

https://github.com/grisu/gricli/commit/6196d5623b3d8fe8f119fc1b5aa3a7aa8f90cea9

[ndjones]

Suggestions for information to display, on successful login:

• listing of current jobs (current active jobs, jobs completed "since last login", jobs' queue status) "Jobs: 20 active, 10 completed since 20 July 2011, 14,000 in queues: 12,000 short-jobs.auckland; 2,000 mpi.canterbury"
• system maintenance messages (not sure where we get these.. MDS?) "NIWA HPCF is scheduled for maintenance from x to y"
• quota remaining/out of total (once we have this) "20,000/50,000 hours"
• service notices (e.g. "Resource Grant Applications are currently open, see: http://www.nesi.org.nz/apply"

[ndjones]

Hi Markus, welcome back to NeSI.

Jobs: 20 active, 10 completed since 20 July 2011, 14,000 in queues: 12,000 short-jobs.auckland; 2,000 mpi.canterburyNIWA Quota: 20,000/50,000 hours Maintenance: HPCF is scheduled for maintenance from x to y

Notices:

• Resource Grant Applications are currently open, see: http://www.nesi.org.nz/apply

[ndjones]

@smas036 - perhaps something for you to check on with users, once @makkus and @yuriyh established what is feasible

[makkus]

Hm, I guess this kind of information would be good to have anyway, right? I.e. display some of them as news items, having a webpage where statistics are displayed as graphs, sending out outages notes.

Wondering if that isn't enough scope to be a project of it's own, maybe summer of eresearch? Not even talking about how and where to present this info, but figuring out what to collect and how to store it. Then we could tap into this pool from wherever we need...

Shame that mds/bdii/iis (or whatever the new globus thing is called) don't cover all of this...

[ndjones]

Is there any of this, perhaps the personlisation and job status info, that we could display now?

[makkus]

I guess @yuriyh can answer job status info. Not sure about personalisation, we may be able to put name of user in /etc/passwd and get it from there. But that would be just a workaround until we have proper user management (like pretty much everything we're doing at the moment, thinking about it :-) )

[ndjones]

We couldn't extract it from cert?

On 21/07/11 4:30 AM, "makkus" reply@reply.github.com wrote:

name of user

[makkus]

This is different. Cert/proxy is inside gricli. This script would execute on machine level, so it wouldn't have any knowledge about gricli-session things. Except we give them as parameters...

Anyway, hard to parse dn of cert because of stupid sharedToken...

[sina-masoud-ansari]

Sorry didn't seem to be getting emails on this one, The customised messages would be great, sounds like we can get a name and possibly a job summary. Happy to work with users on presentation and other info when we've decided what we can provide.

[yuriyh]

i don't understand why we need it. we have griclish wrapper, so it is possible to execute shell commands before launching gricli. gricli could preset environment variables before launching its own script, but i cannot see any usecases.

as for Nick's suggested message:

Jobs: 20 active, 10 completed since 20 July 2011, 14,000 in queues: 12,000 short-jobs.auckland; 2,000 mpi.canterburyNIWA Quota: 20,000/50,000 hours Maintenance: HPCF is scheduled for maintenance from x to y

we cannot get this information anyway.

[makkus]

So, what's the plan? What exactly do you guys want to display here? Not sure how to proceed with this ticket...

[ndjones]

Want to display more information to the user, when they start griclish. From what i understand we could print: active job # by status. eg. queued: 10, active: 12

The point is to be thinking about providing richer context information to users as they come in, so they know what progress has been made etc. And we would then look to extend this, as our information sources become richer.

[makkus]

Nick, do you mean # active, # queued jobs per user or per cluster or grid-wide? If per user, then we don't need an external shell script, because Gricli has internal knowledge (a shell script wouldn't even be able to get that kind of info) about that. Be aware, though, that this will slow down the login process since we can't load that in the background (since we want to display it to the user first thing). Gricli login will feel less snappy...

It'd be basically a print jobs command with a bit of processing to figure out # of jobs.

[ndjones]

Had discussed with Yuriy a month back, and he suggested shell scripts, or perhaps I misheard..

Yea, aggregate per user # active, # queued, and we could likely say print jobs for more information or some such helpful thing.

Keen to see the impact/responsiveness, though guess it would be close to print jobs speed - I'd assume you've already squeezed as much out in terms of speed as you can.

[makkus]

Ok, how about I implement it and enable it in the dev version. Then we can have a look how fast/slow it feels in comparison. Those jobs need to be loaded sooner or later, but we could do that (at least in part) in the background until now...

[yuriyh]

loaded sooner or later not necessarily. and performance will depend on how many jobs are there.

Excerpts from reply+i-1214791-b352193d6a35dd289decffe10356411e92b13a61's message of Fri Aug 19 19:35:39 +1200 2011:

Ok, how about I implement it and enable it in the dev version. Then we can have a look how fast/slow it feels in comparison. Those jobs need to be loaded sooner or later, but we could do that (at least in part) in the background until now...

[makkus]

All right, implemented "status" command. Added it to gricli commands for now, so it can be run manually as well, not just at startup (for testing -- will remove it again later on).

Have a look and see whether you think it takes too long. As Yuriy said, it depends on how many jobs are there...

There is some display issue at the moment where some characters from the loading string remain, but I don't really care to fix it just yet. Only if we decide to use this...

[ndjones]

Seems to work well... Runs slightly faster than the cached session restart on login, and slightly slower by a second or two than the session login from a restarted backend. For 20 active jobs. Would be good to test with 100, 1000

[ndjones]

I just logged in, and I got the following information on login, which seemed to be cached:

[njon001@login1 ~]$ /opt/griclish-dev/griclish-dev -b dev
Logged in to backend: dev
Active jobs: 20 -
Finished jobs: 2
gricli> print jobs
gricli : Done
gricli_1 : Done
gricli_10 : Done
gricli_11 : Done
gricli_12 : Done
gricli_13 : Done
gricli_14 : Done
gricli_15 : Done
gricli_16 : Done
gricli_17 : Done
gricli_18 : Done
gricli_19 : Done
gricli_2 : Done
gricli_3 : Done
gricli_4 : Done
gricli_5 : Done
gricli_6 : Done
gricli_7 : Done
gricli_8 : Done
gricli_9 : Done
nick007 : Done
nicks-echo : Done

Running status by itself a little later returned correct summary:

gricli> status
Active jobs: 0
Finished jobs: 22

After quit, logging back in again returned correct number.

[ndjones]

@makkus could you take a look at the cache and format issues?

[yuriyh]

current slow down is annoying and information is usually useless. Granted, my usage patterns are unusual, but I don't think that users would want to see job stats on every login.

And if they do, they can put status into config file.

[ndjones]

can u turn it off, in your config file?

guidance should be on by default tho able to be turned off.

nick 021 609 535

On 24/08/2011, at 11:42 AM, "yuriyh" reply@reply.github.com wrote:

current slow down is annoying and information is usually useless. Granted, my usage patterns are unusual, but I don't think that users would want to see job stats on every login.

And if they do, they can put status into config file.

Reply to this email directly or view it on GitHub: https://github.com/grisu/gricli/issues/80#issuecomment-1885377

[makkus]

Currently we don't have a config option (and a place for config options like this) to disable that (enabling, on the other hand, could be done in config file).

Have to say I agree with Yuriy and think this should be an "opt-in" option. Just not that useful and one can call the information manually if one really wants...

[makkus]

As for the job status caching issue:

Couldn't reproduce that. How long did you wait between the last session and the new one? Internally, Grisu doesn't update the job again if it was checked within the last xxx seconds (configurable) -- even between sessions.

[ndjones]

Currently we don't have a config option (and a place for config options like this) to disable that (enabling, on the other hand, could be done in config file).

so we would need to create a default config file for each new user, to enable by default?

[makkus]

So, what do we do? @yuriyh, is there an easy way to disable this in a config file? For example, is there something like a gricli.config file we could use for that? Or should we disable it via env-variable?

[yuriyh]

env variable. is the best, I think. Unless we choose sensible option of having it off by default.

[ndjones]

we need a way of switching it off/on by default. We can deploy with this release, switched off, so that @smas036 can then do testing with users

[makkus]

Ok, disabled in code for this milestone, "status" command is still there and can be used for testing with users. Moving issue to next milestone...

[makkus]

Assigned to @smas036 for review of currently implemented status command. Happy to take over after that again if you give me directions on what to implement...

[makkus]

Moving out of milestone until we have more information to present or know otherwise what we want to do here...

[makkus]

Closing this. Will reopen or create new one once we know what kind of information we actually want to display. Gricli is prepared to run external scripts on startup, anyway...