June 27, 2011

PoD in PROOF connection string

Anar here...

I am very glad to confirm, that PoD is now officially supported as one of the PROOF connection strings.
To connect to a local or remote (managed by new pod-remote) PoD cluster you can just enter:

TProof::Open("pod://");

This feature is already in the trunk of ROOT and will be released with the next production ROOT 5.30.

June 14, 2011

pod-remote


Anar here...

It has been a long time since my last post... :) 

I am very excited right now, because in this post I am going to introduce to you a new PoD development. Another big step forward for PoD!
This is a fresh stuff, which is not completely finished yet, but already in a good and usable shape. ;)

So, it is pod-remote. A new command of PoD.

I've been dreaming for a long time about having a possibility to control PoD Servers from a remote machine. I mean, I have all my work, development, analysis scripts on a laptop and I want to use some remote machines as my PoD/PROOF servers, some with LSF, some with PBS, some with SSH plug-ins.
But my work stays on my laptop (or other dedicated desktop machine) and hasn't to be copied if I want to use different PoD/PROOF servers.
  
PoD UI and PROOF UI are lightweight entities and they don't do much. I even might want to have my UI on an iOS device ;)
With pod-remote my dream is coming to reality and starting to have a shape...

Using pod-remote it is possible to start/restart/stop remote PoD servers. It is possible to submit jobs from remote PoD servers. Most importantly, pod-remote automatically creates and handles SSH tunnels for remote PoD servers, so that these servers can be used only via SSH connection - outside of a firewall. Another important feature of pod-remote is its integration into PoD.

There is no yet a documentation for pod-remote, but I can give you a simple use case, so that you get the picture.

Let us say, I have two machines A and B.
A (host: demac012) - is my laptop.
B (host: lxg0527) - is a machine standing somewhere at my work place. From this machine I can submit jobs to my batch system (LSF) or use it as a server for PoD SSH plug-in.

On both machines I have PoD installed.

All the following I do from my laptop (machine A, "demac012").

  1. Start the remote PoD server:  
    pod-remote --start --remote manafov@lxg0527.gsi.de:/misc/manafov/PoD/3.5.75.gbecd4 --env ../GSI_env_5_27.sh

    --start - start the server
    manafov@lxg0527.gsi.de:/misc/manafov/PoD/3.5.75.gbecd4 - a connection string to the server, including a full path to a PoD installation
    --env - an environment file, which will be executed on the remote-end before PoD starts the server. In my case I just source a proper ROOT version in it. You can set some more env. variables if needed.

    pod-remote will remember your settings and next time you want to stop/start/restart this server you can just write: pod-remote --start(stop/restart)
    without --remote and --env. The command will always use the latest given settings.
    If you want to change the server, just provide new arguments values.

    if everything is OK and remote server is started, pod-remote will create and manage special SSH tunnels from machine A to B. So, the whole PoD communication and PROOF requests will go via these tunnels.
    Tunnels stay alive until remote server is alive or you restart/stop pod-remote. The pod-remote command creates a background daemon, which regularly checks the status of the remote PoD server and manages tunnels.  


  2. Submit PoD jobs from the remote Server (in case of RMS plug-ins):
    pod-remote --command "pod-submit -r lsf -n 50 -q my_lsf_queue"
    or in case of ssh plug-in
    pod-remote --command "pod-ssh -c --submit"

    Using --command, you can execute any command vie SSH on the remote server.
    I am going to keep it that way for a timebeing, and see whether it is usfull to wrap "submit commands" into sub-options or keep it as generic as it is. I like to have it that way and let users have the flexibility to execute any remote command and wrap commands for their special needs/environments.
  3. Now, you can just use pod-info as usual, as if everything would run locally:
    pod-info -s
    pod-info -c
    pod-info -n
    ...
    The pod-info automatically detects that there is a pod-remote-managed server and will gather the information directly from it via the SSH tunnels.
    It means, of course, that to connect from your local machine (a laptop) to your remote PoD/PROOF cluster you need just to use:
    TProof::Open(gSystem->GetFromPipe("pod-info -c"));

    That's it!
The second time I want to use the remote server I have to just execute the following on my local machine:  
pod-remote --start (note: no other arguments, pod-remote remembers my settings)
pod-info -n (note: no need to use --remote here. The pod-info command handles pod-remote automatically)
root[] TProof::Open(gSystem->GetFromPipe("pod-info -c"));

to stop the server: pod-remote --stop
or it will use standard PoD idling timeouts...

You can use your laptop, your development machine as a command center.
Don't need to copy analysis code or to have different machines for different PROOF clusters.
Don't need to handle SSH tunnels by hands and so on and so on...

Please give it a try and send me your feedback. The pod-remote command is available in PoD starting from PoD v3.5.75.
The pod-remote command will be a part of upcoming stable release PoD v3.6.

If you want to try this build, please download the latest Beta: http://pod.gsi.de/download.html
In case of Problems: http://pod.gsi.de/support.htm

P.S. As soon as PoD v3.6 is out I am going to record a screen-cast demonstrating pod-remote use cases ;)