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

[Maria Alandes Pradillo]

Dear Paul,

> > Paul Millar [mailto:paul.millar at desy.de] said:
> >> Since the attribute is optional, existing publishers will continue to
> >> work, but will refrain from publishing a ViewID attribute.
> >> Since not publishing ViewID places the Storage Share objects in the
> >> same view, the GLUE 2.0 SharingID semantics is preserved.
> >
> > What about the client side - will a client which doesn't know about
> > the new attribute be able to make sense of data which uses it?
> 
> Certainly if the schema is updated but no info-provider publishes a ViewID then it
> is completely backwards compatible, even with a mixture of GLUE 2.0 and GLUE
> 2.1 clients.
> 
> If there are GLUE 2.1 info-providers publishing ViewID values then GLUE
> 2.0 clients will treat all Storage Shares as belonging to the same view.
>   This might or might not cause a problem, but only for clients that are doing
> accounting by aggregating shares.
> 
> The update I have in mind specifically for dCache would publish the same set of
> shares, but with different ViewID values.  Therefore, at least for dCache, GLUE
> 2.0 clients would not be affected by the change.
> 
> If a GLUE 2.1 info-provider wanted to make use of Views then there is a risk of
> confusing GLUE 2.0 clients that aggregate shares to do accounting.  I think this
> scenario is pretty unlikely.
> 
> To put this in context, storage accounting is currently broken in dCache as we
> must publish both SRM reservations and the underlying storage.  I think adding
> views is the best way of fixing the problem.

If we need to write GLUE 2.1 info providers this is not in my opinion a backwards compatible change. One thing is to add new entities for Cloud, which is something that requires new info providers in any case and it's mostly affecting a few sites right now, and another thing is to add a new attribute that requires new info providers to make use of it. This will require a coordinated deployment to be able to make use of the View concept.

Could you please explain why suddenly this is an issue, who has requested this use case, how many VOs or users are affected otherwise and why it can't be addressed with the existing GLUE 2.0 schema? This is not clear to me. Before proposing the change to the GLUE WG, I think we need further discussion also among the rest of the Storage developers. What happens with DPM or StoRM? If they don't publish this attribute, will those sites or users who have requested that use case be happy? Will they target only dCache installations? I would like all Storage systems to be aligned. I don't like the idea that we introduce an optional attribute that will be mandatory for dCache but not for the others.

And why do you say that storage accounting is broken in dCache only now? This is the first time I hear this, when I have spent the whole summer trying to improve storage info providers and the feedback I got from dCache is that everything was OK for GLUE 2 publishing.

Thanks!
Maria