[Swift-devel] Status of coasters
Mats Rynge
rynge at renci.org
Fri Feb 13 13:28:57 CST 2009
Mihael Hategan wrote:
> ----- Mats Rynge <rynge at renci.org> wrote:
>> Ioan Raicu wrote:
>>> Although, we and others have been doing this (multi-level scheduling)
>>> for a while now, using Coasters, Falkon, Condor glide-ins, etc... I
>>> don't see what would be different, to set up a separate WS-GRAM
>>> interface on a site that doesn't support it. Its just another method, to
>>> do multi-level scheduling.
>> No. The problem here is that you want to directly interact with the lrm.
>> This will break several things such as accounting, and lrm policies. It
>> is similar to use jobmanger-fork to run condor_submit. Even though it is
>> technically possibly to do so, most OSG sites would find such a behavior
>> unacceptable and probably ban the user/VO doing it.
>
> I assumed the LRM does the accounting.
I don't know details on how this works, but I think there are some OSG
and/or VDT patches to the jobmanager perl modules. Think about it as the
LRM does the accounting, but you have to pass the LRM the correct
information. If you interacted directly with the LRM, the jobs would
look like local jobs, not OSG originated jobs.
>> This is different from for example glideins, where you use the existing
>> interface and lrm to get slots allocated to you, and then your job is
>> actually the glidein. The WS-GRAM on the side would be the same iif you
>> submitted it to the lrm, started it on compute nodes and only used
>> jobmanager-fork (but only one real job at once). This would obviously
>> not be very helpful as many compute nodes are behind NAT.
>>
>> You really should not user jobmanager-fork for anything except simple
>> setup/cleanup jobs.
>
> That doesn't leave many options. If we have a more efficient way of
> submitting to the LRM than GRAM2, we can't use it. If we have more-user
> friendly way of doing glide-ins, we can't use that either. We're pretty
> much at the mercy of the VDT, which doesn't, after many years, properly
> escape whitespace. I find that to be an affront to the users and
> ultimately to the taxpayer.
I agree with you, but standing up your own WS-GRAM is not the solution.
--
Mats Rynge
Renaissance Computing Institute <http://www.renci.org>
More information about the Swift-devel
mailing list