[Swift-devel] Status of coasters

[Mihael Hategan]

----- 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.

> 
> 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.