[glue-wg] Comparison with CIM

[Burke, S (Stephen)]

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.

> 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.

> 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. 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.
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 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.

Stephen