On Sun, 30 Mar 2008, Maarten Litmaath wrote:
Ciao Sergio,
* For Storage Share 1- add a shared attribute in the storage share which type is boolean; for "shared" shares, the value should be true 2- add an AggregationLocalID attribute; for the "shared" shares within the same storage service, this attribute should be assigned with the same value
in this way, we avoid the creation of one more level of hierarchy and potential visualization tools which want to show a summary info can avoid double counting by checking the two attributes that we propose
So, you would publish such a shared Share multiple times, once per VO. Each such instance then gives a VO view of that Share. I do not see a problem for the info provider to cook up the correct values for the boolean flag and the AggregationLocalID, but I do note that compared to the proposal by Felix we lose some functionality: if each of the VOs has a _quota_ in the Share, we would publish that number as, say, its online TotalSize --> this means we no longer have the _physical_ TotalSize of the Share published anywhere. Maybe not a big loss...
I would like to remind that NorduGrid has declared this accounting per tape/disk as a use case. For WLCG both solutions are fine since they have one Share/UserDomain. I personally don't see any design problems and think that this is more than 'nice-to-have'. However, if there are problems implementing/using such mechanism which _overload_ the advantages then we should drop it.
* For Storage Resource: since information about free/used/total/reserved space is provided by the storage environment, we could avoid to have summary info at the storage resource level; information consumer can aggregate it
The assumption then is that Environments will not overlap: probably OK.
I would quite prefer having a Share always linked to a _single_ Environment, which itself will have an online component and may also have a nearline component. We will discuss this on the next storage discussion (Thursday,03.04). From
The Capacity->Resource link has been removed (v.32) and there will a note in the description of the Environment about the fact of non-overlapping. the main entities point of view we don't have any restrictions. One reason I remember for this current relation was to be aligned with the computing model (share-executionenviroment).
If we want to have separate implementation names and versions for those components, it would seem natural to introduce the split at the Resource level instead: an Environment can be linked to an online Resource (e.g. with GPFS 3.2) and a nearline Resource (TSM X.Y.Z).
Whichever way, we would like to publish such back-end implementation names and versions explicitly. Flavia has a use case: the name and version of the back-end storage system should be available, such that it can be deduced from the information system which sites are likely to suffer from which open issues. This is important information for debugging operational problems in WLCG (and other grids).
I agree. But this can also happen in a OtherInfo field. And I tend to this rather making entities too complicated. Sergio, should I postpone this issue until you're back with us (9.04.2008) ? Cheerio, Felix