[glue-wg] Comparison with CIM

[Owen Synge]

On Tue, 29 Apr 2008 17:07:03 +0100
"Burke, S (Stephen)" <S.Burke at rl.ac.uk> wrote:

> glue-wg-bounces at ogf.org 
> > [mailto:glue-wg-bounces at ogf.org] On Behalf Of Paul Millar said:
> > My view is GLUE 
> > simply shouldn't publish any ACL information: a simple link 
> > from UserDomain 
> > to the objects that UserDomain might interact with should be 
> > sufficient, 
> > right?  At worse, people try a service and find out they're 
> > not authorised 
> > (which is an inevitable possibility, as GLUE can never 
> > publish all ACEs).
> 


Dear Steven, 

> I think a key point in all these discussions is to remember that we're
> always striking a balance, and practicality is more important than
> purity.

On this issue I agree, but I disagree with you suggesting that we
represent standard ACL's and leave out Castor and DPM due to the low
level of storage deployment they have compared to dCache.

I think if VO's if they set ACL's will be aware of what they set and all
they need to know is if a service is up and how to write to it.

Can you please explain why more is needed for Glue?

>  It's certainly true that we can't publish all ACLs at an
> arbitrary level of detail. On the other hand the main purpose of GLUE is
> to allow a client to prune the range of resources it has to deal with -
> if you have to contact 500 services to find the one that authorises you
> then you probably have a problem. 

I quite agree, this is why we publish VO as an attribute to entities.
To supplement this we can discover the implementation of a service and
its version number. From this we can inquire the access and publish it
at a VO level.

> I think the way to deal with that is
> for the schema to define the format, and individual grids can then
> decide what level of detail is needed for their community.

I assume you mean ACL's. Provided you have an answer why VO's will need
ACL's published is it wise to couple our selves to the dCache
implementations so preventing future enhancements to the ACL model by
Storm, Castor or DPM, and forcing them to comply to dCache?

Storm, DPM and Castor that together make up 1/3 of the storage in wLCG
and should not be overlooked. NorduGrid and OSG do not use these
minority storage elements but I should not like wLCG to be damaged by
Glue turning into a requirements source, just for a desire for
standardisation on the cross product of VO specific settings and
service implementation on Castor's already overstretched support teams
when Nordu Grid and OSG impose a dCache implementation of ACL's.

Regards

Owen Synge