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

[Maria Alandes Pradillo]

Dear Stephen,

> Providing the numbers manually every month sounds quite labour-intensive - if
> we could show that a simple query would reliably produce the information
> automatically it seems hard to believe that people wouldn't prefer to use it. But
> anyway, the question of whether we have current uses for information isn't
> really the right argument - we have many attributes which aren't used at the
> moment. The question is whether the information is potentially useful -
> changing the schema is so slow and infrequent that we need to look at
> possibilities a long way in the future. Adding one new attribute is a rather
> lightweight thing to do so I don't think it needs a very strong justification. What
> we do need to be sure of is that the attribute is well-defined, satisfies the
> identified use-case and would not disrupt the existing usage.

I don´t think there is a use case. Only one site has asked for it. If Paul would like to convince WLCG to use the BDII to rely on installed capacities, he would need to present this at the GDB, after having agreed with all other storage systems that it is feasible to have reliable numbers published by them too. Something which we don´t know. Otherwise, there is little chance that all this effort is useful at all. Making this work for dCache is not enough. It has to work for all available storage systems. That is why requesting this new attribute in the GLUE WG at this point doesn´t make sense. And I can already tell you from conversations with the WLCG management that there is no interest to have this in the BDII because there is this manual mechanism in place which have been used for many months now and which they rely on.

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? 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´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?

Why is dCache publishing space tokens and physical space? Is this needed? How is this done in DPM or StoRM? Do they have the same problem? I think we have another forum to discuss this things before coming to the GLUE WG with a concrete proposal. I would start there first. I am interested in getting storage capacity properly published in the BDII and I have attempted to get this right for many months. I´m happy to see interest on this particular subject. In any case, I´m not interested in getting this right for the WLCG accounting use case, as I said it´s not needed there, but because experiments have expressed they wouldn´t like to rely on SRM for getting storage capacities. This is why I have set up the BDII vs SRM comparators in the dashboard for ATLAS and LHCb, which by the way, look pretty well, which means that for these use cases we are doing pretty well, also dCache:

http://wlcg-mon.cern.ch/dashboard/request.py/siteview#currentView=BDII+vs+SRM+ATLAS+Storage
http://wlcg-mon.cern.ch/dashboard/request.py/siteview#currentView=BDII+vs+SRM+LHCb+Storage


Regards,
Maria