On Fri, 2 May 2008 20:01:32 +0200 <Maarten.Litmaath@cern.ch> wrote: Hello Maarten,
I would suggest you all consider that wLCG should first agree on a format before we try and put it in GLUE, I hope you agree?
No. GLUE should allow the _notion_ of ACLs to be expressed where they might reasonably be needed. And we already have ACLs, namely ACBRs. They do not impose particular semantics.
I would suggest ACBRs are incomplete and not rich enough to be of much use, mainly because they do not impose particular semantics, and map poorly to a ACL, so as to be misleading.
Instead they allow for any schema and schema-dependent notions to be expressed. The VO and VOMS schemas are just popular examples of an open-ended enumeration. A grid can decide which schemas it supports.
I am happy to standardise where things are needed, and support adding Name spaces as a new Glue service for example. I am less happy to express things in GLUE particularly if it puts sites in a position of conflict of interest, I fear that ACL's are coupled with the concept of where experimental VO's want to store data rather than within the concept of Site VO's.
We can all pick our own preferred standard, and our favourite implementation, but this in no way effects anything as the outcome (can we write or read) will always resolve to TRUE or FALSE for a given operation, do you agree?
Since the outcome resolves to TRUE or FALSE and experiments store where they write data, the experiment is better placed to store the resolved value since this is both already stored and already expressed in a standardised way, for example in FOC?
That is a slippery slope. You could do away with most if not all of the information expressible in GLUE: it could all be remembered in VO-specific services...
Certainly this argument could be taken a lot further and I would encourage it, but it definitely could not remove all details from GLUE, which is used to discover available services. In this case, it is an especially pragmatic solution. Other similar arguments are that I would not expect to standardise experimental work flow as they will all work their own way. Furthermore standardising on an incomplete ACL implementation would in my opinion just be misleading and effort. Worse than this they will cause confusion in the comprehension for users. VO's will not find much use in reducing ACL's to a misleading 1 dimensional enumeration unless they are limited to use no more than a 1 dimensional enumeration.
That happens to be what some of the LHC experiments are doing, but that was because of (past) instabilities in the standard information system. We would not want to give VOs even more reasons for bypassing it...
Here I disagree, I know the LHC experiments are blacklisting and white listing sites. I even know sites strive to get back on experimental white lists, as we all want jobs to successfully run at our own sites. Do you agree that white listing is an alternative justification for LHC experiments enhancing GLUE to their own needs?
I am sorry but GLUE cannot be everything, I see it as an advertising service, upon which other things can represent information. I hope others also recognise the point of the FOC initiative, and if they do, and still favor ACL's they should explain why they dont see it as part of FOC?
Advertizing what? "You might store a file here, just try it and remember the outcome for the next time?"
Yes exactly. Please don't confuse GLUE as a mechanism to declare that services exist with the concept of services will be used. White listing of sites is even performed by the VO EGEE. (we call it SFT's) pilot jobs should be embraced by the wLCG community and we should learn the lessons as the Grids evolve to a more workable environments and not just for compute but also storage. As you say LHC experiments already do this and for many good reasons, one of many is that GLUE can never be a complete model only a representation of a site by a site. Site functional tests are an example of this by the VO wLCG. White lists for specific tasks cover all the so far suggested reasons for ACL's within GLUE. ACL's evaluate to TRUE or FALSE for READ and WRITE operations and can be set by VO's. Its the experimental VO's business to even allow them to be read by third parties. Sites that are removed from white lists already strive to be put back on white lists. White and Black listing, Reliability metrics and work flow hints, such as to migrate data from a site after processing is exactly the remit of publish and subscribe systems and they are fit for this purpose but outside the scope of GLUE, as GLUE is provided by sites not by experiments. Experiments would never white list a storage area they had denied them selves access to. Publishing sites service in GLUE, which are refined by white listing of services covers all the use cases presented for ACL's within GLUE and should not be provided by GLUE as they are experiment specific and not site specific. I am yet to see a use case for ACL's within GLUE, not covered by experiments own whitelists, maybe people advocating them are not justifying the case for them in GLUE adequately for me to understand or their is no reason to include them in GLUE. Regards Owen Synge