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

Maria Alandes Pradillo Maria.Alandes.Pradillo at cern.ch
Mon Sep 29 04:43:42 EDT 2014


Dear Stephen,

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

If I understood it correctly, Paul is saying he wants to change this because one site would like to calculate installed capacities for WLCG using the BDII. I know the grid world is not only WLCG. I'm saying WLCG has other means to collect this information, so I'm not sure the effort required to implement and deploy this is worth it, WLCG is not going to use it. If there are other use cases apart for WLCG, Paul hasn't mentioned them. I also said dCache is of course free to choose where they put their effort and what new features they want to implement. But when it comes to something that is used by other services and it's meant to help in terms of interoperability, I think further discussion is needed. Not only with the GLUE WG.
 
> 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.

As I already said, for me it would make more sense if Paul presents this to other storage developers and see whether the idea could be interesting for them too and whether it fits for them or needs to be adapted a little bit. Coming directly to the GLUE WG, getting this approved and then having it in GLUE 2.1, doesn't seem to be very fair for the others. When they want to react, maybe it will be too late. When will we have another GLUE 2.2 or something similar? Getting new versions of the schema approved and deployed is a very long process.
 
> 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.

Well, this is not so clear to me. If dCache introduces the ViewID, what should ginfo do? Should it have an option to get this information? How will users know that actually only dCache provides ViewID? It will be misleading. That is why for me it's dangerous to say, "this is only for dCache". Well, it's mandatory for dCache and dCache is going to rely on it, whereas the others are not going to publish it at all. This doesn't sound very consistent to me.

Regards,
Maria
 


More information about the glue-wg mailing list