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

[Paul Millar]

Hi all,

Sorry, my email client decided to sent the reply directly to Maria, so 
I'm forwarding it here.

-------- Forwarded Message --------

Hi Maria,

I started off replying generally, rather than point-for-point, but have
included some specific points where it makes sense.

Yes, dCache instances would move to GLUE 2.1 info-providers, but I would
hope to do that anyway.

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

I mean that, for dCache:

   a. an SRM share do not overlap with any other SRM share.

   b. a Physical share do not overlap with any other physical share.

   c. a Physical share may overlap with a SRM share.

Statement b. isn't completely true currently (as expressed by the
SharingID), but I aim to fix that soon.

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

Yes, that's exactly right!

The problem is GLUE 2.0 has no way for me to say "these shares are
different from those ones", or "these shares are the ones to use for
storage accounting".

The ViewID is aimed exactly at fixing this: I give all the physical
shares the same ViewID ("physical" say) and all the SRM shares the same
ViewID ("srm-reservations", say) and then it's easy to select the
Physical shares.

> What is then published in GLUE2StorageServiceCapacity? The total
> of Physical Shares?

Yes.

> But who has asked for this? My understanding is that nobody
> is interested on relying on the BDII for this.

I had to smile inwardly here ... Yes, there was an effort, starting
around five years ago, in precisely this direction:

https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/WLCG_GlueSchemaUsage-1.8.pdf

"The goal of this document is to detail how to use the Glue Schema
version 1.3 in order to publish information to provide the WLCG
management with a view of the total installed capacity and resource
usage by the VOs at sites. This information can also be used by VO
operations and management in order to monitor the VO usage of the resource"

Myself (and others) invested considerable time in trying to provide
these numbers with GLUE 1.3.  GLUE 2.0 was developed with this use-case
in mind, albeit (from memory) not extensively reviewed.

> [...] I´m not sure is a use case we would like to address.

It seems at least one site wishes to make use of these numbers and to
automate the process.  I don't think we should give up, just because the
problem isn't solved yet.

> 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

I believe there are many factors influencing such dependencies; however,
this would suggest a need for more automation, not less.

Such dependencies should be investigated and understood.

Yes, more work is needed, investigations, etc; however, we have to start
somewhere, so I gave a concrete proposal so people have something they
can understand: a straw-man they can hack away at.

Cheers,

Paul.