[glue-wg] Capacity representation

[Paul Millar]

Hi Sergio, Stephen,

On Wednesday 09 April 2008 17:44:30 Sergio Andreozzi wrote:
> Burke, S (Stephen) wrote:
> > On the Capacity issue, I think one source of confusion is that the
> > current document shows a single Capacity with three lines linking it to
> > share, MappingPolicy and Environment. That's misleading, because a
> > single instance of Capacity can only ever be linked to one of those.

Yes, absolutely, I think separating them would be much less confusing.

> [...]
> If we want to keep a common definition for the set of attributes which
> are in the storageCapacity class, then we could do it.
> But this should be treated as an abstract class from which other classes
> inherits the common attributes.

OK.  My understanding was that this subclassing was happening implicitly, but 
that it wasn't worth trying to express these subclasses as they hold the same 
(mostly optional) attributes (Of course, I may be alone with that 
understanding :-)

If it looks cleared expressing the three different StorageCapacity classes 
(StorageShareCapacity, StorageEnvironmentCapacity, 
StorageMappingPolicyCapacity, I guess) as subclasses of some generic 
StorageCapacity class, then I'm happy with that.

[...]
> > For
> > this kind of thing I think it would be better to have three separate
> > Capacity boxes, each linked to only one other object, to make it clear
> > that Capacity is an attribute of some other thing (the Capacity of this
> > Share, etc).

Yup, fair enough.

> > In fact the link to MappingPolicy shouldn't be there at all 
> > because it's another example of the same kind of thing: a Mapping Policy
> > is an ACL, which has no independent existence, it's also just an
> > attribute of something else (Share in this case).  There are other things 
> > in the schema which behave like that, e.g. Location (you can only talk
> > about the Location of some other thing).
>
> I understand that this was added to deal with the issue of a "Shared
> Share", i.e., what is the used size by a certain userDomain if different
> userDomains can access the same storageShare?
> how would you address this?

Moreover, we have a use-case for doing VO-based accounting of StorageShares. I 
believe Nordogrid want to share StorageShares between VOs and account for 
their separate usage.

In this case, the Mapping Policy is more than just an ACL.  The MappingPolicy 
(i.e., the ability for a VO to use a StorageShare) has properties like 
usedSize.

[No independent existence => should be an attribute]

As a counter-example, the same is true for the CE-SE-Bind (in whatever form it 
might take).  This leads no independent existence from the CE and SE it 
connects, yet is represented as an object.

I would suggest that the CE-SE-Bind is represented as an object class because 
the link must have additional attributes (that qualify and describe the link) 
in order to satisfy the use-cases.  Simply having an attribute "closeSE" in 
the CE objects is insufficient.

So, I'd propose a rule-of-thumb: a conceptual link between two objects should 
be an attribute unless metadata must be recorded about the link.

HTH,

Paul.