Thread: Re: [Fwd: Re: [Chromium-environment] Some starting discussion...]

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

>
>
>
>I think I understand some of the high-level goals for this but
>I'm not 100% sure how to boil it down to concrete items for
>implementation.
>
>I guess I'm picturing at least the following:
>
>1. A node/host allocator which keeps track of the free and in-use
>nodes in a cluster.  A client (like Chromium) would ask the allocator
>for N nodes and get back a list of N hostnames (or an error code).
>When Chromium's finished with the nodes they'd be returned to the
>free pool.

I had a slightly different model in mind.  There would be a "node
allocator" and it would be invoked for a given job (in our case,
it would be DPCS or RMS).  The user would request a number of nodes.
In many cases, the allocator would actually run the user's application
(often an MPI application).  As part of the "job setup" the node
allocator would do, it would configure and launch Chromium as
a service for that job.

FYI: DPCS does the following:

1) user asks for N nodes/CPUs and gives the name of an MPI app.
2) DPCS "finds" the N nodes and configures them for an MPI job.
3) DPCS runs a "prologue" script on each node.
4) DPCS runs the application from (1)
5) at the end of the app, DPCS runs an "epilogue" script on each node.

One more odd (but extremely common in production environments) case
is where the user uses a "squatter" MPI job to hold down nodes.  Since
most "node allocation" systems (like DPCS) are really MPI job schedulers,
they want to run the app for the user.  If the user's app is not MPI
based (and a number of viz apps are not), it is common for users to
run a dummy MPI job that often spits out the setup info for their
non-MPI app.  Again, this should map well to the scheme I suggest.
The user can run all the apps they want on the nodes they have
allocated using the same Cr services.  Key here is that the invoked
mothership must be able to handle more that one app in the "job" space.

>2. Dynamic Cr config scripts which know how to work with the allocator
>in (1).  Either the config scripts would ask the allocator for N nodes
>or a list of nodes would be passed in as an argument.

Yes!

>3. A set of "standardized" configuration scripts for sort-first,
>sort-last which can work with a range of applications and satisify
>item (2).

Yes!

>4. Some system to automatically choose a standarized config script
>based on the name of the program being run, or the the user's requested
>rendering style (sort first/last).  Perhaps libcrfaker could look at
>argc/argv and look up the name of a config script in a resource file,
>then automatically start the mothership with that config script.  Or,
>look for a special environment variable.

You got it.  I would suggest the choice be made based on app name
overridden by environmental variable, overridden by a Cr "Parameter"
call made by the application before it opens a context.

Thanks.

>-Brian
>
>_______________________________________________
>Chromium-environment mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-environment

rjf.

Randall Frank                           | Email:  rj...@ll...
Lawrence Livermore National Laboratory  | Office: B451 R2039
P.O. Box 808, Mailstop:L-561            | Voice:  (925) 423-9399
Livermore, CA 94550                     | Fax:    (925) 423-8704