WIPACrepo/pyglidein

Mechanism for configuring pyglideins to only run jobs matching certain conditions, for instance belong to a given user

gonzalomerino opened this issue · 4 comments

I think this will be convenient to have as we open the pyglidein pool to all IceCube users.

For some resources, it will be just OK to allow any user to run there. But I am imagining that for some others we will want to have the capability to configure them to be "exclusive" for simulation production for instance. I am thinking about resources like allocations we get in Supercomputers or in places where we actually write a proposal on what exactly want to do with the allocation.

Anyway, there are probably several ways to do this in Condor. It would seem convenient to have a way to configure this in the condor CM, so that we have it centralized.

However, at this point I can only think of a way to do this in the pyglidein client. This would be modifying the START expression that we configure in the glidein_start.sh with something like this:

$ diff glidein_start.sh glidein_start.sh.simprod

< export _condor_START="ifThenElse(ifThenElse(MY.GPUs =!= undefined,MY.GPUs,0) > 0,ifThenElse(TARGET.RequestGPUs =!= undefined,TARGET.RequestGPUs,0) > 0,TRUE)";

export _condor_START="ifThenElse(ifThenElse(MY.GPUs =!= undefined,MY.GPUs,0) > 0,ifThenElse(TARGET.RequestGPUs =!= undefined,TARGET.RequestGPUs,0) > 0,TRUE) && regexp("ice3simusr",Owner)";

It looks like that is by far the easiest way, though there might be something possible with setting a rank of 0 in the negotiator. Needs more thought.

Looking at negotiator rank, this won't quite work. While it works fine if there are other available starters, it doesn't work when the protected starter is the only one available.

I am a little worried about the combinatorics of this. We might be adding like 3 class ads right off the bat (production_only, production_pingu_only, production_gen2_only`). What are the applications we are aiming at here.

Talking with @briedel, here's an idea:

3 tiers of sites:

  • Restricted: site will only run jobs with a classad set
  • Preferred: site prefers jobs with a classad, but will also run other jobs
  • Open: run all jobs with no preferences (what we have now)

Implemented with user-submitted classads (as mentioned above) that the startd can restrict or rank as needed.