[glue-wg] Comparison with CIM

[owen.synge at desy.de]

On Fri, 2 May 2008 20:01:32 +0200
<Maarten.Litmaath at 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