Hi Felix, today I won't be able to connect due to phone/network unavailability here at CNAF because of our data center renovation. Tomorrow, I plan to stay at home so I can call/connect. Anyway, I'm sending you a number of thoughts on the current storage entities model: - "Shared" Storage Share the solution of relating a storage capacity to a storage mapping policy to advertise used space per policy seems to over-complicate the model; the storage capacity concept is being adopted by different entities with slightly different meaning and this leads to a not very intuitive and usable model; our proposal is to act as follows: * 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 * For Storage Environment: when we mapped the current model to our T1 use case, we found out that the storage environment is homogeneous; therefore there is not need (at least for our scenario) to have the capacity to be associated to the storage environment; the attributes of the storage capacity can be added to the storage environment * 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 If the above considerations fit the use cases of other partners, then the storage capacity would be related only to the storage share. As regards the today agenda, I removed the following issues since they do not properly reflect our scenario . ** consequence of overlapping StorageResource entities *** GPFS 3.1 and GPFS 3.2 share same disks *** if wished to be expressed explicitly -> each GPFS is represented as own StorageResource *** BUT then : a higher aggregation of capacity numbers muster be given in the service (again: if wished) *** OR (easier): express GPFS 3.1 and 3.2 in OtherInfo field in our mapping choice, we have decided to model the three storage systems managed by GPFS 3.1, GPFS 3.2 and TSM respectively using the storage environment concept. They do not logically overlap. (See here http://glueman.svn.sourceforge.net/viewvc/*checkout*/glueman/tags/glue-xsd/d...) In our scenario, we have one global storage resource composed by three storage environments. As a final comment, my opinion is that we should privilege simplicity and the meta-scheduling use cases more than the monitoring ones. If we do not manage to converge shortly on a common vision for the storage resource/storage environment, we should probably postpone the definition of these entities to a future GLUE revision and concentrate on the storage endpoint/storage share consolidation. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi