[Swift-devel] Status of coasters

[Michael Wilde]

Tim, we should take your advice under advisement.

I can only leave the merits and cost/benefit assessment of this approach 
to you GT4 experts (Ben, Mihael, Tim, ...)

Im open to the idea, and it sounds like its not totally off the table, 
but it has some costs and some unknowns.

The diagram Ben suggests can also be expressed as a list of config 
alternatives, essentially an embellishment of the 
jobmanager=service-submitter:worker-submitter:worker-submitter-jobmanager 
string.

The first message on this thread started to enumerate coaster config 
alternatives.

I suggest we (or I) clarify those into a clean list.

Then we can comment on the cost/benefit tradeoffs of the different 
alternatives, and denote which ones have been tested, which ones should 
be tested, and which ones need how much development work. I think 
there's some obvious "low hanging fruit"-ful ones that float to the top, 
  which we can test, debug, and harden now, and some that require more 
development, some of which has greater additional benefits (like a good 
Condor provider).

If a user-config for a WS-GRAM container proved easier than expected, 
possibly with help from you, Tim, or from other GRAM experts, then 
perhaps it can stay on the table.

- Mike


On 2/13/09 9:40 AM, Tim Freeman wrote:
> On Fri, 13 Feb 2009 09:32:43 -0600
> Mihael Hategan <hategan at mcs.anl.gov> wrote:
> 
>> On Fri, 2009-02-13 at 09:23 -0600, Michael Wilde wrote:
>>> On 2/13/09 9:17 AM, Mihael Hategan wrote:
>>>> On Fri, 2009-02-13 at 08:59 -0600, Michael Wilde wrote:
>>>>> -- Service submits via WS-GRAM. This should be tested, on sites where 
>>>>> WS-GRAM is working.
>>>>> This woild use jobmanager=gt2:gt4:{pbs/condor/sge}, and needs to be
>>>>> tested. For sites where WS-GRAM is not functional, I suggested we
>>>>> consider configuring our own non-root WS-GRAM, ideally using
>>>>> already-installed GT4 software, eg, from the OSG package on OSG and TG
>>>>> sites where its installed. Mihael thought this would be considerable
>>>>> work. 
>>>> Not as much the amount of work, but:
>>>> 1. getting root on sites (if installed for multiple users)
>>> I was thinking/hoping we could have a single setup script, which we'd 
>>> pre-install where required, that would configure and start a personal 
>>> WSRF container for the user. Which would be work for us to create, 
>>> install and maintain, but, if successful, would be transparent to the user.
>> You need root to configure sudo.
> 
> Why would you need sudo for gram if it mapped to the same account?
> 
>> I also don't think you can easily automate the gt4 installation process.
>> There's manual configuration that needs to be done. I suggest installing
>> your own gt4 once to which I can submit jobs to get an idea of what's
>> involved.
> 
> For non-gram, there's an auto script here:
> 
>     http://workspace.globus.org/vm/TP2.2/admin/quickstart.html#auto-container
> 
> The questions it asks users (is this the right hostname? etc) could also be
> scripted.
> 
> Getting from there to GRAM4 auto-configuration should not be too much of a step
> (the nimbus contextualization scripts have done it for gram4).
> 
> Tim