On Wed, 9 Apr 2008, Paul Millar wrote:
b. some places have operation practise that they "just add more tapes" when the space looks like its filling up,
In that case it may still be interesting to publish the current total.
| In general, a StorageEnvironment may have one or more | RetentionPolicy values.
Not what it says in the current draft (0..1).
True ... I thought we had agreed that StorageEnvironment had 0..* multiplicity, but the docs don't seem reflect this.
I argued that GLUE probably should allow for the RP being multi-valued, and probably the AccessLatency as well. In WLCG/EGEE we would have a single value for each normally, so that the Storage Class is clear.
Does this correspond with SRM usage, i.e. can you have spaces with multiple RPs?
From memory, I believe this was a request from Maartin: that a StorageEnvironment could have multiple RPs. I'm not sure precisely why: perhaps indicating that a StorageShare may have different RPs, but this would be covered by the (potentially) one-to-many link between StorageShare and StorageEnvironment.
I did not ask for that (see my comment about the StorageEnvironment). In fact, I think a Share must belong to a single Environment, as I see it as a chunk that is carved out of a particular Environment.
What about defaults for other things, e.g. ExpirationMode?
I'm not sure having multiple ExpirationMode makes sense. If, for some reason, two ExpirationModes need to be indicated, could this be done with two different StorageEnvironments?
No. I argued that in SRM v2.2 the ExpirationMode (a.k.a. Type) does not behave like RP and AL: a space that is defined by RP and AL may support multiple ExpirationModes. In a particular space a file may have a finite or an infinite lifetime; the SRM may support either or both. So, at least ExpirationMode we would want to be multi-valued within the Environment.
If a StorageEnvironment is advertised as having a RetentionPolicy Custodial (only) and has two StorageCapacity (a nearline one and an online one), would that be OK?
In WLCG it would seem natural to identify an Environment with a Storage Class, in which case the RP and AL need to be treated together.
Maybe we should look back at the proposal for Storage Components made by Flavia, Maarten et al in the 1.3 discussion, or has someone already done that?
I'm not sure ... I don't think I've seen it. Do you a copy somewhere?
https://forge.gridforum.org/sf/go/doc14619?nav=1
A StorageShare is a logical partitioning of one or more StorageEnvironments.
Maybe I'm missing something, but how could you have more than one Environment for a single Share?
I think this isn't something useful to EGEE and it comes from one of the other grids.
Certainly our current structure doesn't allow it (one SA per many VOInfos but not vice versa), although as I said above that might be misleading.
Yes, I believe this was to allow a new, non-WLCG use-case. I have a vague memory of Maarten mentioning this, but I could be wrong.
See earlier comments. Thanks, Maarten