[glue-wg] Comparison with CIM

[owen.synge at desy.de]

On Thu, 1 May 2008 11:52:23 +0100
"Burke, S (Stephen)" <S.Burke at rl.ac.uk> wrote:

> Owen Synge [mailto:owen.synge at desy.de] said:
> > 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 didn't say anything about specific implementations. My point is that
> GLUE is about interoperability, and if the underlying middleware isn't
> interoperable then GLUE can't do much about it. To the extent that it is
> interoperable, e.g. in LCG via the SRM MOU, we then have a question
> about how much of that needs to be advertised in GLUE.

Im glad you agree, I only picked an implementation that seemed clearly
the most logical for the purposes of clarification.

 
> > 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?
> 
> In practice it doesn't work like that. For example, sites may set up
> their CEs to give priority to particular groups within a VO, so a user
> needs a view of the system which relates to the share of resources they
> will get mapped to. In general the VO users aren't aware of how all the
> sites are configured, and in any case you also need to know the dynamic
> state, e.g. how many jobs are in fact running for each group. Hence we
> have a use case to publish Shares with an ACL to say which users are
> authorised to use which Shares. For storage the analogue is to know
> whether there is a Share (space) which you are authorised to write to,
> and if there is whether it has enough free space to store your data.
> What is not so clear to me is whether we have a use case to publish more
> detailed authorisation - i.e. a situation where you know you are
> authorised and there is enough space, but you need to discover exactly
> where in the namespace you should be writing.

Thankyou for explaining, but Im still confused why this should be in
GLUE, when its dependent on who reads the ACL.

ACL's are not static (which Glue is designed for).

ACL's may be private (which Glue is not for).

Experiments have the Freedom of choice project to say where they want
to write. 

 
> > 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?
> 
> As I say, I didn't say anything about dcache specifically. From a purely
> LCG/EGEE perspective it's actually the DPM authorisation model we would
> like to have and dcache and castor should come in line. 

This is a mater of opinion, I suggest prime mover advantage is
important but not the only factor in desiding.

> For GLUE it
> doesn't really matter, we just define an abstract format which can
> (hopefully) be specialised according to the needs of particular grids.

I still feel ACL's are wrong in GLUE for many reasons but I am very
pleased that you should think this way.

> However, it seems that the lack of convergence in authz models has
> pushed LCG into asking to have two separate kinds of authz (on
> namespaces and space tokens) and that does need to be considered for
> GLUE because it would affect the model, e.g. Flavia's proposal to have a
> new object for namespaces.

I feel my proposal for VO-Objects and specialisations target at
services and VO's appeals more and more.

> > I should not like wLCG to be damaged by
> > Glue turning into a requirements source,
> 
> As far as I'm concerned it's the other way around, my primary interest
> is in LCG/EGEE and I want to try to ensure that GLUE can represent the
> important use cases for that community. If other communities want
> different things I think it's up to them to make sure they get
> considered.

Just because I oppose the complete idea of ACL's in Glue specifically
does not imply I don't think that experiments should and need to get
their job done.

I am wanting us to do a good job to satisfy wLCG, I think though
sometimes wLCG as a collective does a bad job at service decomposition,
I often blame myself for backing down too often when I see us making
mistakes just because I'm in a minority.

I just want to throw out some things from GLUE as I see that they are
misplaced, and better solutions exist, FOC (Or a second schema) being a
better place for storing what we want to know in this case, which is
not ACL's, but where a particular experiment can store data.

Regards

Owen Synge