[PATCH] bjs xcpu nodename fixes

[Abhishek Kulkarni]

This patch fixes two minor bugs with bjs.
Interactive job submission didn't set the NODES environ variable correctly. A check to ensure if the requested nodes are less than or equal to the nodes in a pool was added back.

Signed-off-by: Abhishek Kulkarni <adku...@cs.indiana.edu>

Index: bjs.c
===================================================================
--- bjs.c    (revision 751)
+++ bjs.c    (working copy)
@@ -581,7 +581,7 @@
     sexp_append_atom(sx, tmp);
     for (l = j->nodes.next; l != &j->nodes; l = l->next) {
     struct node_alloc_t *n = list_entry(l,struct node_alloc_t,nodes_list);
-    sprintf(tmp, "%d", bjs_node_idx[n->node]->node);
+    sprintf(tmp, "%s", bjs_node_idx[n->node]->node->name);
     sexp_append_atom(sx, tmp);
     }
     client_send_sx(j->client, sx);
@@ -1149,13 +1149,11 @@
         return -1;
     }
     } else {
-    /* FIXME
     if (nodes > p->nnodes) {
         bjs_client_error(c, "The maximum number of nodes for pool"
                  " %s is %d.", p->name, p->nnodes);
         return -1;
-    }
-    */
+    }   
     }
 
     /*--- Check number of seconds requested ---*/

[Latchesar Ionkov]

Acked-by: Latchesar Ionkov <lu...@ionkov.net>

[Daniel Gruner]

Allright! we seem to be getting there. I will test running some
scripts for actual jobs on my cluster, and will report back to you.

Thanks!
Daniel

[Daniel Gruner]

Here is one problem:

Say I run a batch job:

bjssub -i -n 2 -s 10000 /bin/bash

I get the two nodes, and the environment is set to NODES=n0000,n0001
All this is fine. However, when I try to xrx anything, it forces the
NODES value as the set of nodes where the stuff runs, and doesn't stop
to check if there is another option on the command line. E.g.:

[danny@dgk3 ~]$ xrx -p date
n0000: Wed Dec 17 23:35:00 UTC 2008
n0001: Wed Dec 17 22:33:41 UTC 2008
[danny@dgk3 ~]$ xrx n0001 date
Error: bad command name: no file "n0001" in $PATH

Should the behaviour not be to use the command line first and only
then default to the NODES environment variable? Take the example of
obtaining a node to run stuff in. In my case I have several cores per
node, so I want to run several different jobs. If I only get a single
node, then it should not be a problem (assuming you can put the xrx
command in the background). However, if I ask for several nodes, I
may still want control of where to submit all these jobs. In the
latter case simply doing "xrx command" will send the command to both
nodes, thus running two instances when I may not want that.

In my bproc clusters I parse the NODES variable in order to decide
where to run my jobs using bpsh.

Daniel

[Abhishek Kulkarni]

On Wed, Dec 17, 2008 at 3:52 PM, Daniel Gruner <dgr...@gmail.com> wrote:

Here is one problem:

Say I run a batch job:

    bjssub -i -n 2 -s 10000 /bin/bash

I get the two nodes, and the environment is set to NODES=n0000,n0001
All this is fine.  However, when I try to xrx anything, it forces the
NODES value as the set of nodes where the stuff runs, and doesn't stop
to check if there is another option on the command line.  E.g.:

[danny@dgk3 ~]$ xrx -p date
n0000: Wed Dec 17 23:35:00 UTC 2008
n0001: Wed Dec 17 22:33:41 UTC 2008
[danny@dgk3 ~]$ xrx n0001 date
Error: bad command name: no file "n0001" in $PATH

Should the behaviour not be to use the command line first and only
then default to the NODES environment variable?  

Yes, this crossed me yesterday. The command line should override the environment variable.
I'll send in a patch.