On 24/09/14 13:28, stephen.burke@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@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. Cheers, Paul.