[torquedev] Mod we use at Harte-Hanks

Garrick Staples garrick at clusterresources.com
Wed Jul 26 14:02:57 MDT 2006


On Wed, Jul 26, 2006 at 04:37:39PM -0400, Caird, Andrew J alleged:
> > -----Original Message-----
> > From: torquedev-bounces at supercluster.org
> > [mailto:torquedev-bounces at supercluster.org] On Behalf Of Garrick 
> > Staples
> > Sent: Wednesday, July 26, 2006 3:15 PM
> > To: torquedev at supercluster.org
> > Subject: Re: [torquedev] Mod we use at Harte-Hanks
> > 
> > On Wed, Jul 26, 2006 at 03:51:28PM -0400, Caird, Andrew J alleged:
> > > 
> > > Is this pretty much the same as moab's GRES functionality?
> > > 
> > > 
> > http://www.clusterresources.com/products/mwm/docs/12.5generalresources
> > .shtml
> > > 
> > > Not that I think that's bad (or good), I'm just checking.
> > 
> > I don't think so.  GRES is per-node, while these tokens are floating 
> > server-wide.
> 
> I think GRES is floating.  We use it that way and the title of the
> section at the URL above implies floating "12.5.2  Configuring Generic
> Consumable Floating Resources".

Ah, I see.  By using the GLOBAL psuedo-node, you get something that
floats.  That's pretty cool.

But now back to his patch... besides being reversed and including extra
diffs, it looks pretty safe to merge.  Without commenting on the
stability of the code, it looks like it isn't touched if you don't use
it.

Except for this weird bit...

  static int set_tokens(attr, new, op)
        struct attribute *attr;
        struct attribute *new;
        enum batch_op op;
  {
   ...
    file = fopen("/tmp/rescheck", "a");

    fprintf(file, "attr is %s\n", attr->at_val.at_str);
    fflush(file);
    fprintf(file, "new is %s\n", new->at_val.at_str);
    fflush(file);
    fclose(file);




More information about the torquedev mailing list