[glue-wg] Fwd: Re: New attribute for GLUE 2.1: StorageShare.ViewID

[stephen.burke at stfc.ac.uk]

Maria Alandes Pradillo [mailto:Maria.Alandes.Pradillo at cern.ch] said:
> I don´t think there is a use case. Only one site has asked for it.

The use case is from dcache itself - Paul is saying that there is significant information about dcache that he can't publish now and would like to. The work to implement that would be on the dcache team, so as far as I can see it's mainly a matter for them whether they think it's worthwhile. I don't see why LCG would have a case to object to it, as long as the new information would not interfere with anything that LCG does care about. What exactly is your objection to Paul's proposal, i.e. what harm do you think it does? "Not needed by LCG" is not an objection - the Grid world is not only LCG!

> Adding one attribute may be a rather lightweight thing to do, but I think it
> needs a very strong justification. What happens if tomorrow StoRM asks for
> another one, DPM for a different one, and maybe CREAM CE too?

If they did I would be pleased, because it would show they were taking an interest in GLUE. This is the first chance we've had to add things to GLUE since 2008, and it could easily be many years before there's another one. People should indeed take this opportunity to consider whether there are things which were missed in the original specification but which are potentially useful. If something gets added which turns out not to be useful it does no particular harm, it just doesn't get published, but if you leave something out and then realise you do want it there's nothing that can be done until the next revision.

> It may be
> optional attributes for the others that may not disrupt existing info providers
> but it´s fundamentally wrong. The schema should be the same for all the
> services, we can´t make exceptions. The schema shouldn´t adapt to the
> services but the services to the schema, and if something is missing, it should
> be something missing for all, not for one service.

I think that's the wrong way to look at it. One of the basic problems with GLUE 1 was that we tied it too specifically to the particular services we had at the time. For GLUE 2 we tried to have a much more general structure which could be adapted to the needs of many different services. The schema itself is of course the same for all services, but the details of how it's used may well not be.

In this particular case it has always been true that dcache implements reservations [1] (SRM spaces) in a fundamentally different way to the other SEs. I don't think it's in any way realistic to say that services have to adapt their mode of operation to the schema - the point of the schema is to be able to describe services as they are. The reason something here is missing for dcache and not, say, DPM, is that dcache doesn't work like DPM, so assumptions which are true for DPM are not true for dcache.

> I´m a bit scared with this
> change, because if we agree we do this for dCache, we may have to face
> similar requests in the future as well and what are we going to say?

I would say the same things I'm saying now!

Stephen

[1] My analogy is hotels vs restaurants. A restaurant reserves a specific table, so you can query any of its properties in advance. A hotel usually only picks which room to give you when you arrive at the desk, so before that you can't query its properties, only the properties of the reservation (e.g. non-smoking). 

-- 
Scanned by iCritical.