[glue-wg] Some thoughts on storage objects

[Burke, S (Stephen)]

Still going back over the previous mails ...

glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Jensen, J (Jens) said:
> It may be better to provide attributes for ExpirationMode and
> RetentionPolicy (etc) and explain what they're for, but not to
> prescribe the values.

I think we have two possibilities there: either allow open enumerations
for the values, as you suggest, or define those attributes to be
SRM-specific and provide different attributes for non-SRM use. The first
one is obviously easier, but might cause problems e.g. if a differt
technology also had a Replica QOS but meant something different by it.
However, I guess we could just insist that the name mustn't clash. Since
we don't really have any other examples we can't do much more.
(Presumably even future SRM versions might have more/different
categories?)

> For example, if a StorageEnvironment contains both tape and disk, its
> AccessLatency should be Nearline - as it is the lowest common
> denominator.
> 
> This only makes sense if you have a partial order on capabilities.

In LCG that would clearly be wrong, we *define* Disk1Tape1 to mean
Online! I think this needs more thought. Similarly you could argue that
any SE which can provide Custodial storage must be good enough for
Replica - but you may not want to use it for that if it costs more, and
maybe the SRM does not in fact accept requests for Replica spaces (or
does it have to?).

> 3. A StorageShare is associated with a StorageEnvironment if and only
>     if they contain a common StorageCapacity.

I can't resist pointing out that this language implies that a Capacity
has an identity - what does "common" mean? The thing which is common is
the hardware (Datastore), not the Capacity, indeed the value of the
capacity (number of bytes) is likely to be different (the Share usually
doesn't fill the whole storage).

> Where did the network description go?  We used to have one.
> 
> The idea is that certain protocols can be used only locally, or on
> certain networks.

It was considered to be too complicated to represent all the
possibilities (potentially everything could depend on everything else!).

> I think we need to put it back, and StorageAccessProtocol seems to me
> the more obvious location.

Maybe, but we need a concrete use case which is likely to occur (and be
important) in the real world.

Stephen