[torquedev] Approach towards small vs. big patches

Christopher Samuel samuel at unimelb.edu.au
Thu Nov 25 17:34:52 MST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Simon,

Sorry for the delay, back from SC'10 and slowly getting
over jetlag..

On 20/11/10 18:29, "Mgr. Šimon Tóth" wrote:

>>> My patch is extreme in this context. I know it's huge.
>>
>> I think it may be more subtle than that, it's against the
>> pbs_scheduler and I don't think many (or maybe even any)
>> of us use it and so don't really feel qualified to comment
>> on it.
> 
> Well the question more or less is if Torque should be just
> a job storage system (as used by external schedulers) or if
> it should have its own logic.

Personally I'd say it's a resource manager, and the scheduler
is the thing that decides where and when something has to run
based upon its policies and the resources that Torque has either
been configured to know about or has been able to discover itself.

I was agitating at SC'10 for Torque to include hwloc so that it
could start to discover more about the topology of the system it
was running on in a more portable way.

> What the patch is doing is improving the internal logic drastically.

OK, I will try and find some time to look at it and see if
I can wrap my head around what it does - please remember I'm
not a coder, I'm just a sysadmin. :-)

>> I'm certainly hesitant because (a) I'm not a coder and
>> (b) I'd like someone who has looked at it to figure out
>> whether it affects how other schedulers (Maui, Moab) talk
>> to it.
> 
> Should be completely orthogonal. I have several confirmations that these
> schedulers do indeed send very specific run commands into Torque (and
> manage all resource semantics internally).

OK - has anyone tested this against Maui and/or Moab and
confirmed that it doesn't break them ?

>> I also think that bugzilla makes it hard to discuss patches,
>> I much prefer the mailing list for that (though yes, I am
>> not too good at keeping up with that either).
> 
> Bugzilla is total overkill for Torque.

I disagree, it's fine for keeping track of bugs (and we can
see when we have outstanding issues), but I don't think it's
really a replacement for an email list for discussions such as
this.

> There was some discussion about a Trac installation, but nothing
> happened. Trac would be optimal for Torque. It's simple, has an
> integrated wiki, integrated code browser and what few features are
> missing are provided by plugins.

I'm abivalent on Trac, I hate having another thing to try
and keep track of (if you'll pardon the pun).  I'm much
happier with just bugzilla and the mailing list.

cheers,
Chris
- -- 
 Christopher Samuel - Senior Systems Administrator
 VLSCI - Victorian Life Sciences Computational Initiative
 Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
         http://www.vlsci.unimelb.edu.au/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzvAKwACgkQO2KABBYQAh+HfQCfUUBt2aXq5f+5Wy9lvzdQtwLn
h44An3YEBcQnbXzoY1ml3K4pwHZaDdez
=ANq4
-----END PGP SIGNATURE-----


More information about the torquedev mailing list