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

[Maria Alandes Pradillo]

Dear Paul,

> Some groups (like dCache) may *choose* to write a GLUE 2.1 info-provider to
> better describe the storage; however, existing (GLUE 2.0) info-providers will
> continue to work fine.

I guess your intention would be that all dCache instances move to the new GLUE 2.1 info provider if this is finally written, right?

> The Storage Shares representing physical hardware were intended for "installed
> capacity" calculations.
> 
> I know that, for at least one Tier-1, the installed capacity numbers are provided
> as a spreadsheet and are calculated manually, NOT from information published
> by GLUE.  I suspect this is true for other sites, but I could be wrong here.

This is my understanding as well. In many cases I think the BDII is not used.
 
> The problem is that, for dCache, the Storage Shares representing SRM space-
> reservations and those representing physical hardware are two views on the
> same storage which overlap.  The Storage Shares in the "SRM space-
> reservations" view do not overlap.  Similarly, the Storage Shares in the "physical
> hardware" view do not overlap.

Do you mean SRM shares could overlap with Physical Shares or do you mean that SRM shares overlap among themselves and the same with Physical Shares? In any case, if only Physical Shares are intended to be used for installed capacity, this should be the ones used by sites who may want to rely on the BDII for installed capacities, right? 

What is then published in GLUE2StorageServiceCapacity? The total of Physical Shares?
 
> The ultimate use-case is for calculating the installed capacity, which is a long
> established use-case in WLCG.  I believe introducing an extra attribute is needed
> to provide the necessary information for a dCache instance.

But who has asked for this? My understanding is that nobody is interested on relying on the BDII for this. This is the reason why REBUS offers now an interface to sites to manually enter this information for the monthly WLCG reports. I´m not sure is a use case we would like to address. I made a comparison in February between WLCG Accounting reports and what the BDII and REBUS were publishing in terms of installed capacities. And I think there was no single match for any T1:
http://wlcg-mon.cern.ch/dashboard/request.py/siteview#currentView=WLCG+Accounting+vs+BDII

Obviously, the sites are reporting things that somehow are not reflected on the BDII. But obviously this is not an issue, since for WLCG what matters is what they put in their monthly reports manually.
 
> Because GLUE 2.0 provides only the SharingID attribute, which describes
> whether or not two Storage Shares overlap.  This is not a rich enough language
> to describe a dCache instance.

Why is not enough for dCache? Is it enough for the other storage services? I read the definition of your new ViewID attribute and I find it complex to understand. It looks like a SharingID attribute but with more complexity added. Moreover the capacities are published in the StorageShareCapacity object, so how would sites know which StorageShareCapacity object they have to use to calculate the installed capacity and how will the ViewID attribute help to make this correct in the future, if now it´s not correct?
 
> I thought the GLUE WG was the correct place to discuss a proposed change to
> GLUE.

Well, as I said, I would like all storage systems to be aligned. In this working group there are no representatives of DPM or StoRM, for instance.
 
> They need do nothing: the proposed change is backwards compatible for GLUE
> 2.0 info-providers.

Well, it would be good to understand whether what you want to change could be also useful for them. If we introduce a new attribute, maybe this could also be useful for them. 
 
>  > I would like all Storage systems to be aligned.
> 
> Me too.  Currently they are not.  I would like to change this; hence the proposal.

Sorry, I don´t see how this proposal makes storage systems to be aligned. Moreover, it is trying to address a use case that is nowadays implemented in REBUS through manual editing of the installed capacities. For sure the WLCG management hasn´t asked for this, I still wonder who is now asking for it.
 
> The point here is that GLUE 2.0 is incapable of describing a dCache site in such a
> way that the installed capacity may be calculated from the published data.

Have you get in touch with i.e. FZK, IN2P3, NDGF, SARA, TRIUMF or pic, just to mention some of the T1s using dCache, and ask them how they provide their installed capacities to WLCG and if they actually need this feature you want to implement?
 
> GLUE 2.0 is "broken" in the sense that it cannot describe a dCache site such that
> the installed capacity may be calculated.  I would like to "fix" GLUE 2.0 so an
> info-provider can describe a dCache instance.

As I have already said, I´m not sure this is an actual problem. But I guess it´s also up to you to decide which new features are available in dCache.

Regards,
Maria