VOStore interface

Paul Harrison pharriso at eso.org
Wed Aug 3 05:12:53 PDT 2005


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



More information about the vospace mailing list