[glue-wg] Updated thoughts...

[Maarten.Litmaath at cern.ch]

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