Hi Maria, On 26/09/14 14:27, Maria Alandes Pradillo wrote:
As you say, Physical shares do not publish the Tag attribute, so it's easy to know which ones they are.
It doesn't say that in the GLUE 2.0. It says "An identifier defined by a User Domain which identifies a Share with a specific set of properties." There's nothing written *anywhere* that says only shares without a Tag should be used for accounting. Also, introducing such a rule could break the existing info-providers: what about DPM and StoRM? The point is: yes, I can publish something in dCache info-provider that allows a client to get the right answer, but either the client needs to know some dCache-special thing, or the solution is fragile and will break in the future. What I want (and what you said you wanted) was all storage systems to be handled in the same way.
That document is for GLUE 1.3. We don't have something similar for GLUE 2.0.
True, we hoped it wouldn't be necessary to have a special document for GLUE 2.0 as GLUE 2.0 should handle this use-case without profiling.
And I can tell you WLCG is not interested in getting installed capacities correctly published in the BDII. They have given up and they have the REBUS interface instead.
Yes, I guess they gave up forcing everyone to use it because the initiative failed --- although nobody in WLCG management has made this explicit. What I'm saying is that not everyone has given up: some people still want to get the numbers this way. If we can fix the accounting then it becomes possible. As you say, the current REBUS accounting is broken: the numbers don't match up. Let's try to fix it.
I wouldn't introduce this change in the schema only because one site has asked for it. Moreover, and after your answer to Stephan (which by the way it's a bit confusing) there are ways for that site to calculate the installed capacity using the current attributes.
The point is that one can always publish "something" and "somehow get it to work". This is how we published SRM information in GLUE 1.3: naming conventions and duplicating information. With GLUE 2.0, we tried to fix that: to get rid of fragile work-arounds like that. The result is much better but there are still problems. We should try to fix those problems. Cheers, Paul.