Job control in grid CLI shell

[tmart]

Is there any way that you guys could easily implement job control in the CLI? For example, sometimes a controller-to-VM connection gets stuck because of not having disconnected from the terminal and it would be handy to be able to for example ~^Z (tilde-Control-Z) out of the ssh -to-component shell to get back to the controller as one could do from a standard ssh shell. This also comes up when we failed to disassociate from the target shell terminal via nohup/screen/etc. but would also be generally convenient for bouncing back & forth between running login shells as one might do from a "jump box."

[LeoKalev]

Job control isn't an "easy" feature by any means - and not many would know how to use it either. If you are like me and enjoy having the full power of a real shell at your fingertips (with redirection, conditionals, loops and all the goodies, in addition to the job control), you should definitely look into using the remote access helper functions that I developed. They allow you to use AppLogic shell commands directly from the 'bash' prompt on your desktop.

For more info see here:
http://doc.3tera.com/AppLogic2/ClientSideMacros.html

The tilde-Ctrl-Z trick will not work out of the box with the shell helper functions described in the doc page above, because they use a multiplexed ssh connection. You could modify them not to do this at all (makes things slower on faraway grids), or use a command like this below if you need a non-multiplexed ssh session to a component from which you want to be able to escape back to your local shell:

ssh -t $AL_SSH_OPT $AL_CTL "sh your-application:your-appliance"

(this will take you to the ssh shell prompt of your appliance and ~^Z will bring you right back to your local shell).

[PeterNic]

I think a more generic solution might work here -- similar to what we're doing with a "job" entity in our API (I'll be happy to share this, PM me if interested).

The idea is that operations that might take indeterminate amount of time -- or all operations if we want to be extreme and consistent -- get run in their own environments, detached from the console. Output is recorded on the controller (memory/file) and available through a pipe; once the CLI initiates a command, it automatically connects to the pipe of the job and displays output and can feed input. It acts as a terminal though, so you can always press ^Z or similar and detach from it. Really it would be more like running 'screen' sessions (and screen might be one approach to simple implementation).

The following might need to be added for this to work:
- "job" CLI entity, including at least a list, info and some sort of "attach" operation; cancel would be nice, too. The cool part is that you might be able to attach to other people's jobs (provided you are permitted to do so). Job list can show the first few words of the command, the user who started it, whether it is currently attached, how long it has been running, etc.
- optional, a "&" character at the end of any command to automatically put the command in background -- or use "job start" command followed by the command to be executed
- optional, ability to schedule a job for future execution (requested by a few customers), say, to resize a volume at 2am or force vol repair

Being able to run "detached" operations will be good as it also eliminates a possible problem with long commands (e.g., migrate) being cancelled if the connection between the user and the grid drops.

Regards,
-- Peter