[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] late binding of universe type

Thanks! The second part that you described is what I was hoping for. Unfortunately the $$() method doesn't work. I appears that the condor_submit command parses the job file and tries to validate the universe entry as well as the remote_universe entry at submit time not at matchmaking. I have tried adding a layer of indirection to get it to defer the validation however it resolves all variables it can and then checks if it is a known universe. any suggestion, or do I need your new daemon.

The reason I ask this weird question is because I would like to figure out after I've submitted a job whether I will be doing a single Condor-C hop to a vanilla/standard universe, or if I will need to make two hops. Right now it seems that the remote_universe entry is what is holding me back from this. Hope this clarifies.

Dan Bradley wrote:
Hi Ryan,

You should be able to use the $$() mechanism for remote_universe, just like any other attribute. In the present scheme, if you want matchmaking to choose between grid and vanilla, you need to submit all of the jobs as grid universe jobs; a portion of those can then match to a Condor-C resource (i.e. a schedd) that will run them as vanilla jobs.

We have a daemon in development that does things the other way around: the jobs run directly as vanilla jobs by default, but under conditions that you can configure and control, they may also match to grid destinations and be transformed into grid jobs.


Ryan Garver wrote:

I'm curious if it is possible to have a remote_universe entry in my job file either fill in at matchmaking time or maybe be chosen from a list. I would like to have a job choose between grid and vanilla. This could be by inserting a variable from the machine class ad or just be a list. Is this even possible? Is there a way to simulate this if it is not?

Condor-users mailing list

Ryan Garver