[ogsa-d-wg] Storage in the Data Architecture

[Allen Luniewski]

On last week's teleconference I took an action to look over the 
architecture document to see if there were places where we needed to 
consider storage more than the document currently does.  I have just 
completed a quick scan of the document and we appear to be in good shape. 
I only detect the following places where we may need to say more:

        1. In Naming (section 3.1) we may want to augment the table with 
some storage specific entities that need to be named.
        2. Section 9 (Caching) needs to discuss where the data being 
cached is stored while on the caching server.  It is not clear
                to me if this should be a file (system) or something from 
storage.  If the cache is perceived to be short lived then one
                might argue that this is just temporary storage and 
nothing need be said to the cache service to tell it where to put
                such transient data.  However, if the cache is perceived 
to be long lived, or even if the amount of cached data will
                be large, the owner of the cache may have a desire to 
control where the data goes.  I am inclined to believe that the 
                latter is the more likely case.  So, I think that there is 
a clear hole here in the description.
        3. In the Creation of Federations (section 11.1), we need, as for 
caching, a means to tell the federation service where it
                should keep any data that it generates in support of the 
federation.  Since this data could be long lived, we will
                inevitably get into storage and storage concepts such as 
lifetime management.
        4. Finally, the caching item above raises the whole question of 
temporary data used by any service in the environment.
                One could argue that the users of the grid system have a 
vested interest in understanding and controlling where
                this temporary data lives, especially if the data is 
either large or relatively long lived.  If you go down this path, it is
                far from clear to me how one meets this need without 
either adding undue complexity to every factory(-like) operation
                or mandating a management interface to every service to 
allow control of the location of the service's temporary
                data.  Personally, I have a slight tendency to not attempt 
to mandate something in this area.  I am inclined to make
                a note in the architecture that there is an issue here 
that every service must address but that it is up to the service
                designer (?) to make the call about how to deal with the 
issue.  Normal market forces would then determine if that
                decision was the proper one.

I don't claim that these are all of the places but it is, hopefully, a 
good start.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20060411/c52121b7/attachment.html