[glue-wg] feedback on storage entities

[Felix Nikolaus Ehm]

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



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