Re: VOStore interface

Reagan Moore wrote:
> The differentiation between the VOStore and VOSpace interfaces is
> becoming unclear. The latest draft implies that properties that were
> originally associated with VOSpace would now be supported by VOStore.
>

I have to say that I agree that there seems to be some confusion in this area - with hindsight it was probably a mistake to defer the specification of VOSpace and work on VOStore alone as the "easier" problem - the specifications should be worked in tandem to see where it is most appropriate to place roles and responsibilities for particular use cases, so that a "global" solution is arrived at.

I thought that the original separation into VOStore and VOSpace was done so that VOStore could be an essentially "dumb" BLOB repository that did what it was told by the VOStore layer when it comes to issues of file permissions and hierarchical file names. However, because no VOSpace specification was created, these more advanced features have crept into the VOStore layer.
>
> Let's look at the current VOStore and VOSpace proposal:
>
> VOStore VOSpace
> Storage of objects management of virtual file
> system
> data stored under unspecified ID?
> no user home directory User home directory
> directory hierarchy Directory hierarchy
> Unique file name within storage User-defined file names
> Mapping VOSpace name to
> VOStore name
> List files for user
> Restrict access by user identity?
> Identify files with URIs
> Access controls on local file name Access controls on VOSPace name
>
> This characterization mixes name space, mixes access controls, does not
> provide consistent identity, does not allow consistent management. For
> instance, if a URI is being provided for file identity within the
> VOStore interface, then there is no need for user-specified names within
> VOSTore. A second issue is the assumption that file access can be
> restricted by user identity. This means that the VOStore must manage
> the owner for each file, access controls for each file. File systems
> usually do this by creating accounts for each user name and applying
> Unix permissions. Is this capability to be provided now by both VOSpace
> and VOStore? We need a cleaner separation of capabilities.

This security aspect is crucial - it is clear that the owners of VOStores would not want to be managing user identity lists of all the VObs users at their stores - the fine grained access controls should be at the VOSpace level. If VOStores only respond to requests from trusted VOSpace services then this is possible, but I think that the perceived requirement for more detailed access control in the VOSpace layer has come about because prototype end-user applications have appeared that talk directly to the VOStore layer - of course, it is not surprising that this has happened because there was no VOSpace definition for the end user applications to talk to.

How file/BLOB identity is managed is also crucial to producing a system that offers more than ftp. I thought that one of the fundamental driving   use cases for a VOSpace was that the same BLOB could potentially live on serveral VOStores, and that when specifying a resource in VOSpace, in a workflow for instance, the resource could be retrieved from the VOStore that was "closest" on the network to where the resource would be consumed. This sort of use case does require some careful thought about the allocation and management of identifiers, and I think probably means that the VOStore will have to be aware of the VOSpace identifier.

I also have an issue with reusing ivo: as the protocol part for the URI of an identifier in this system - ivo: is already well defined and used as the identifer for registry entries, and the "protocol" for accessing the entity associated with the identifier is defined in the registry interface standard. This means that given an identifier of the form ivo://authority.org/something#blah a software agent (or human for that matter) cannot tell by inspection whether the identifier refers to a file in VOSpace or is simply a reference to a registry entry (e.g. for a SkyNode) - this leads to software having to be more complex in order constantly to test for the different possibilities. I think that it would be better to have a URI with a different protocol part, vos: for instance, it would then be immediately apparent that the VOSpace protocol should be used to access the entity referred to by the identifier.

>
> Let's look at the Storage Resource Broker data grid separation of local
> storage management from the virtual file system management:
>
> Local storage system SRB name space
> Storage of objects management of virtual file
> system
> data stored under SRB ID
> no user home directory User home directory
> directory indirection structure Directory hierarchy
> Unique file name within storage User-defined file names
> Mapping SRB name to local
> file name
> List files for user
> Access through SRB ID, controlled by SRB
> Identify files by URIs
> Access controls on SRB name
>

I think that as Regan points out the separation of responsibilities that   SRB has with the local storage system is pretty much the right model for VOSpace and VOStore - though it means that SRB is pretty much at VOSpace level rather than a VOStore as is suggested in the current VOSpace definition document.

-- 
Paul Harrison
ESO Garching
www.eso.org