Hi Greg,
I had indeed thought about machine resources, but that would only work
if there is a known number of resources (e.g. network bandwith), and
those resources would need to be defined beforehand.
Generalising this is currently not possible, since there are no
"wildcard" resources (as there are wildcard currency limits -we use
those as well). I think that would be even harder to implement?
What I'd like is to let users define their own policies, so they could
say that, for instance, different batches of jobs, even from the same
user, should run together as much as possible... or the other way
round... We have multiple use cases here, and want to remain as flexible
as possible.
In fact, this can even be implemented with the current system, but in a
very convoluted way... you can say (if you want only one job running at
a node):
requirements = slot1_1_Tag =!= "MyTag" && slot1_2_Tag =!= "MyTag" &&
slot1_3_Tag =!= "MyTag"...
However, we have some 64-core nodes (and I think that's not so uncommon
nowadays), so this is just a *really* cumbersome way of doing it, at
least compared to:
requirements = !Member("MyTag",ChildTag)
That's why I think this syntax would just expose some functionality that
is already there, but in an much more convenient way, and also more
consistent with the new ClassAd syntax.
Best,
Joan
On 02/04/2016 07:33 PM, Greg Thain wrote:
On 02/04/2016 07:34 AM, Joan Piles wrote:
If you pair it with STARTD_JOB_ATTRS, it would allow you to make cool
things like only allowing one job of a type to run in one machine:
Note that with custom machine resources, defined with
MACHINE_RESOURCE..., HTcondor can do this in a first-class way. GPUs are
a classical example of this kind of resource, but other resources can be
allocated in the same ways.
-greg
_______________________________________________
HTCondor-devel mailing list
HTCondor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel
--
Dr. Joan Piles
ZWE Scientific Computing
Max Planck Institute for Intelligent Systems
(p) +49 7071 601 1750
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
|