On Thu, 1 May 2008 11:52:23 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote:
Owen Synge [mailto:owen.synge@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