Thanks for your input.
My question about an auth check instead of submitting as a test
originated from looking at GridWay within readings and thoughts for my
master thesis. I had read about authorization filtering in [1] and
wondered about the fact that this was the only thing I could not
recognize in GridWay. Because the question "who can use which
resource" seems important to me, I thought it would be the best way to
ask.
Your arguments are obvious and I agree to you.
Thus I currently do not see a need for the mentioned feature.
Regards,
Benjamin
[1] "A General Architecture for Scheduling on the Grid", J. M. Schopf
Am 18.03.2008 um 22:10 schrieb Stuart Martin:
Hi Benjamin,
I agree with Ruben here. Try submitting the job and handle the "not
authorized" reply as the test for that user. A positive test for
authorization successful really only scratches the surface anyway.
For a WS GRAM job, there are many levels where the job can fail.
1) Service authentication (e.g. CA not trusted)
2) Service authorization (e.g. user not trusted / not in gridmap
file)
3) Service mis-configuration
a) local account issues
b) Sudo misconfigured
c) LRM misconfigured (e.g. user not authorized to submit to LRM)
4) Dependent staging service misconfiguration
Any/All of the issues for the above steps for 1 - 3, but for the
staging services (RFT, GridFTP) that WS GRAM is dependent on.
The ping / authorization feature request would only do #1 + 2. I
guess a metascheduler could do this for a user as a test and assume
that the other steps are also setup, but in the end, I think it
makes more sense to just submit the job and see if it works. If it
does keep a history of what worked and how well. Sounds like this
is what GridWay is doing.
One possibility would be to add a GRAM factory RP that is
authorized. Currently, the RPs are not. So, an RP query would not
help do what you want, but this could be added. However, I don't
want to add a new "ping" RP unless it really makes sense. Do you
still see a need for it?
Cheers,
-Stu
On Mar 18, 2008, at Mar 18, 4:52 AM, Ruben S. Montero wrote:
Hi,
In fact, having such a method (auth check) would not provide any
additional
benefit from the meta-scheduler (application) point of view.
GridWay uses the
target job to test authorization,so if the user is in the gridmap-
file no
additional overhead is added, if not you'd have the same overhead
as checking
the authorization. This is if you check the resource before using
it you'd
be adding that overhead to every single job.
Additionally, you have to "remember" those resources that failed
for a given
user (note that the user-specific is quite important here), GridWay
uses an
exponential backoff for this (note also that the initial failure
could not be
related to any authorization issue). So once the system has been
running for
a while GridWay automatically buids a list of authorized resources
for each
user.
Ruben
