Community
Participate
Working Groups
We already associate a spacific credential to a GRIA VO, and a user ID/credential to an Amazon VO. But we need something for GLite also: - we have a VO -> no info about FQAN - we create a project with that VO - we create a proxy with a specific FQAN (either when or before mounting a connection for the first time) - we mount a connection which might only be writable by that specific FQAN (atlas and the other big VOs have those) - we work on that connection, creating data etc. - we restart geclipse - we start to work again on that connection - the connection implementation requests a token... => of course it should request a token with the VO/FQAN used before, not just the VO of the project. BUT the connection/vo/project don't have a way to store/keep/determine that FQAN information. There is also a very related (new) feature used in gLite SE's which we should probably consider in this context: it is called "space tokens" and it is a way of reserving space on a storage element. Actually some LCG VOs now do NOT allow writing on a SE if you do not have a space token! (ie, 0 reserved space if you come without such token). So spaces token info is something which should be also stored somewhere... but they are rather associated to a connection than to a VO...
Ok, now we have the VO being passed to the gsiFTP/SRM/etc filestores, and i also added the FQAN matching code to the VOMS proxy description (mostly untested...). But we still have to way to make use of it... Suggestions?
(See Bug #242564 for the VO passing to the filestores)
> There is also a very related (new) feature used in gLite SE's which we should > probably consider in this context: it is called "space tokens" and it is a way > of reserving space on a storage element. Actually some LCG VOs now do NOT allow > writing on a SE if you do not have a space token! (ie, 0 reserved space if you > come without such token). I have just hit this problem. Atlas is one of the LCG VOs enforcing space tokens. Without this feature, there is no way to store the output of my jobs, right? Do you have a solution or workaround available?
Hi Sander, thanks for your post/remind/request. Yes you are fully right, we still don't support space tokens and i don't think there is a workaround to that except using a non-token protected area. I will open a new Issue for supporting that, it would be nice if you can "enlighten" us there a bit about the usecases, to help define the implementation in a middleware independent way.
> It would be nice if you can "enlighten" us there a bit about > the usecases, to help define the implementation in a middleware > independent way. I'm not a specialist, but here is what I understand so far: - Atlas has assigned space tokens to all VO disk space. - All SRM storage operations need: -s ${SPACETOKEN} - I know what the space token is, or at least I can find out. - In case I try to do a storage operation without the above it will fail. - The failure message is: "no space left on device". The consequences are that my job fails because: - I have the following items in my stage-out: myJob.sterr, myJob.stout, myNTuple.root - These files can only be copied to an SE (right?). - I need these files, otherwise my jobs are useless. - The SE expects a space token, but I can't provide it. * Options that come to mind are: - Provide it during the SE mount and propagate from there. - Provide it in myJob.jsdl - As a result, my job hangs in the running state. * It infinitely tries to copy the files out. * The SE returns "no space left on device". Those are the details of my use case. Do you need anything else? Thanks, Sander
> - I have the following items in my stage-out: > myJob.sterr, myJob.stout, myNTuple.root > - These files can only be copied to an SE (right?). Yes, you're right. A question I have is how you mount your SE's. SRM? What about a plain GSIFTP mount as workaround? Not sure if this needs a space token as well. Maybe this would be worth a test.
> Yes, you're right. A question I have is how you mount your SE's. SRM? What > about a plain GSIFTP mount as workaround? Not sure if this needs a space token > as well. Maybe this would be worth a test. We are testing the GSIFTP workaround at the moment. This will only work for the very short term, since this is no longer supported and will be decommissioned. SRM v2.2 with space tokens will then be the only available protocol.
> We are testing the GSIFTP workaround at the moment. This will only work for the > very short term, since this is no longer supported and will be decommissioned. > SRM v2.2 with space tokens will then be the only available protocol. Ok, understood! In any case it would be good to have a pointer to the documentation of the space tokens or something similar. Otherwise we can of course say nothing about possible integration efforts. Ok, I know about the documentation bottlenecks of gLite, so I do not expect too much here ;-) But every piece of information would of course be very helpful.
> Ok, understood! In any case it would be good to have a pointer to the > documentation of the space tokens or something similar. Otherwise we can of > course say nothing about possible integration efforts. Ok, I know about the > documentation bottlenecks of gLite, so I do not expect too much here ;-) But > every piece of information would of course be very helpful. According to the guys here, the SRM v2.2 MoU has some info about it: http://cd-docdb.fnal.gov/0015/001583/001/SRMLCG-MoU-day2%5B1%5D.pdf I browsed through it, but as you expected... it is not too impressive.
Well, at least space token are mentioned there ... but that's it ... Ok, think we'll have to discuss this within the team ... we'll keep this bug updated.
In terms of SRM and SpaceTokens I would like to join this discussion.
Wait please, i am about to submit a new bug specific for space tokens...
I created Bug #259364 for the space tokens issue. Let's continue there the discussion about the implementation. Sander, answering you Comment #5, > - I have the following items in my stage-out: > myJob.sterr, myJob.stout, myNTuple.root > - These files can only be copied to an SE (right?). no, you can get them also from geclipse directly w/o any SE (chose a local file, as dummy entry when creating the JSDL, the submitted job will get links to the output files which you can click and drag'n drop etc) > - The SE expects a space token, but I can't provide it. > * Options that come to mind are: > - Provide it during the SE mount and propagate from there. > - Provide it in myJob.jsdl if you don't use automatic output registration but use lcg-cr in your wrapper scriopt, you can/will need to enter your ST there BTW, how do you specify a space token in your current ATLAS JDL's?
> > - These files can only be copied to an SE (right?). > > no, you can get them also from geclipse directly w/o any SE (chose a local > file, as dummy entry when creating the JSDL, the submitted job will get links > to the output files which you can click and drag'n drop etc) Okay, for the moment we (Sven) managed to get the GSIFTP workaround working. > > - The SE expects a space token, but I can't provide it. > > * Options that come to mind are: > > - Provide it during the SE mount and propagate from there. > > - Provide it in myJob.jsdl > > if you don't use automatic output registration but use lcg-cr in your wrapper > script, you can/will need to enter your ST there > > BTW, how do you specify a space token in your current ATLAS JDL's? Never used it myself, but from: http://trac.dcache.org/projects/dcache/wiki/manuals/dCache_clients/client_dcache_srm srmcp -space_token=144573 There are more examples of space-token juggling on that site.
