[ogsa-naming-wg] Re: GGF/OGSA standards for hierarchical namespaces

[Christopher Jordan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I won't be able to attend in person, but I should be able to call in  
via skype or old-fashioned phone. We've had some further  
conversations within the GFS-WG, and I look forward to discussing  
this topic with the larger group.

On Apr 3, 2006, at 1:26 PM, Hiro Kishimoto wrote:

> Hi Chris, Allen and Greg,
>
> Thank you very much for this very important proposal.
>
> OGSA-WG will have F2F meeting next week in Sunnyvale
> and OGSA-naming WG's session is 10:30am-12:30pm PDT
> Wednesday April 5.
>
> https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA- 
> F2F-agenda
>
> Chris: If you can join this session either by phone or
> in person, we could have a first open discussion next
> week and follow up at GGF17.
>
> Please let me know your availability. Thanks,
> ----
> Hiro Kishimoto
>
> Gregory Newby wrote:
>> It's not too late to schedule time at GGF17 for a cross-group
>> meeting.  (Well, it's a little too late...but not completely
>> unreasonable to attempt.)
>>   -- Greg
>> On Tue, Mar 28, 2006 at 11:17:54AM -0800, Allen Luniewski wrote:
>>> Chris,
>>>
>>> Thanks for the very thoughtful note!  A few comments.
>>>
>>> I agree with you that the current situation is, to put it mildly,  
>>> not acceptable.  We need to move to a position where the  
>>> community agrees on a single means for creating a hierarchy of  
>>> pointers to resources (a directory structure in Unix-speak).   
>>> Clearly one aspect of this is that RNS and WS-Directory need to  
>>> reconciled into a single proposal. Resolution sooner rather than  
>>> later is clearly in the best interests of the various WGs who  
>>> depend upon directories (including OGSA Data which I share  
>>> responsibility for).
>>>
>>> You mention a couple of specific technical issues.  A few  
>>> comments on those:
>>>        1. I go back and forth on attributes in the directory  
>>> system. Since these are almost certainly cached from the  
>>> resources, today I am inclined to say that
>>>                attributes should not be part of the directory  
>>> system. Ask me tomorrow, and I may have the other answer :-)  But  
>>> today, I would leave them out
>>>                of the base specification for simplicity but  
>>> consider an extension that included attributes if that were felt  
>>> to be vital.
>>>        2. Dave Berry's suggestion to separate out the iterator  
>>> component is a good one.  There are going to be many places in  
>>> the overall grid standards
>>>                effort where an iterator-like structure will be  
>>> needed. Standardizing this seems like a proper goal for GGF.  If  
>>> that is accepted then using it
>>>                in a directory service seems quite natural.
>>>
>>> As for moving forward, I think that we need to see how this  
>>> thread plays out.  My instincts, however, are that getting the  
>>> interested parties in a room for a few hours would be the most  
>>> effective way to drive this to an early resolution.
>>>
>>> Allen Luniewski
>>> IBM Information Management Division
>>> San Jose, California
>>>
>>>
>>>
>>>
>>> Christopher Jordan <ctjordan at sdsc.edu> 03/27/2006 05:28 PM
>>>
>>> To
>>> Osamu Tatebe <o.tatebe at aist.go.jp>
>>> cc
>>> Arun Jagatheesan <arun at sdsc.edu>, Manuel Pereira  
>>> <mpereira at almaden.ibm.com>, Andrew Grimshaw  
>>> <grimshaw at cs.virginia.edu>, Mark Morgan <mmm2a at virginia.edu>,  
>>> Dave Berry <daveb at nesc.ac.uk>, Allen Luniewski  
>>> <luniew at almaden.ibm.com>, Christopher Jordan <ctjordan at sdsc.edu>,  
>>> Hiro Kishimoto <hiro.kishimoto at jp.fujitsu.com>, Ian Foster  
>>> <foster at mcs.anl.gov>, Gregory Newby <newby at arsc.edu>, gfs- 
>>> wg at ggf.org, ogsa-naming-wg at ggf.org
>>> Subject
>>> GGF/OGSA standards for hierarchical namespaces
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> All,
>>>
>>> Forgive the wide distribution on this e-mail, but this issue  
>>> seems to be to be both extraordinarily important to the future of  
>>> GGF/OGSA standards efforts and also in a state of either limbo or  
>>> paralysis. The topic I'm addressing here, both in my capacity as  
>>> the secretary of GFS-WG and as a generally interested participant  
>>> on a few different GGF working groups, is the question of  
>>> adopting a single, possibly minimal, standard for creating  
>>> hierarchically organized collections of pointers (WS-Names? GSR/ 
>>> GSHs, to date myself?) to "resources", where the term "resource"  
>>> could denote a service providing access to a collection of files,  
>>> computational resources, or database records (that's a non- 
>>> exclusive list), and where some items in the hierarchy could  
>>> actually represent directory-like structures, i.e. containers for  
>>> other collections of resources.
>>>
>>> The way I got involved in this discussion through the Grid File  
>>> Systems-WG, which at the time was bringing the RNS specification  
>>> forward for final approval as a GFD. Subsequently, there have  
>>> been numerous discussions outside of the GFS-WG context about the  
>>> suitability of the RNS standard for more general applications, as  
>>> well as the (perceived) complexity of the standard as a barrier  
>>> to entry. There have also been alternative directory construction  
>>> standards proposed by members of the OGSA-Naming-WG.
>>>
>>> The following are the activities/proposals I know of:
>>>
>>> RNS: I know the GGF editors have returned the final(?) RNS draft  
>>> to GFS-WG, with the suggestion that it is too specific to  
>>> filesystem needs, and the suggestion that it either be limited in  
>>> scope to GFS applications only (a non-optimal solution for  
>>> obvious reasons) or that the authors work with the OGSA-Naming  
>>> people to help develop a universal standard for hierarchical  
>>> resource namespaces. If we are to move forward with RNS, one of  
>>> these options will clearly be a necessity, given the points Greg  
>>> Newby made in his responses on behalf of the GFSG.
>>>
>>> WS-Directory: This is the hierarchical namespace standard  
>>> developed at UVa in response to their difficulty in implementing  
>>> the complexities and ambiguities in RNS. I like the simplicity of  
>>> WS- Directory, however it seems to be missing significant  
>>> requirements for general use such as attributes, both attributed  
>>> which should be required such as time-to-live, and the ability to  
>>> add extensibility attributes such as resource type, QoS, etc.  
>>> This ability to add arbitrary attributes is present in RNS but it  
>>> still lacks some obviously fundamental required attributes.
>>>
>>> Finally, Dave Berry sent an e-mail immediately after GGF16 in  
>>> which he mentioned the suggestion that we separate this  
>>> functionality into two logical functions, and therefore standards  
>>> - a Directory Interface and an Iterator interface, in which  
>>> Directory interfaces were essentially just pointers to Iterators,  
>>> which would be standardized. However, there would be no  
>>> restriction that a Directory point to a particular type of  
>>> iterator interface. One point I wasn't clear on from the e-mail  
>>> was whether an entry in an interator could be another directory,  
>>> although I suspect it can.
>>>
>>> This short list is what I've got within easy reach. As I said  
>>> previously, I believe this is an important issue to resolve  
>>> quickly, and I'm sending this note in the hopes of initiating the  
>>> conversation among as many of the relevant parties as I can.  
>>> Please feel free to forward at will, respond with agreement,  
>>> anger, or even unconcealed rage.
>>>
>>> Possible ways forward would be for us to have a conference call  
>>> (GFS- WG meets rarely, and we could quite easily give up our call  
>>> for a more focused discussion of these issues), an extended e- 
>>> mail discussion, or a meeting at the next GGF (assuming we get a  
>>> chance).
>>>
>>> Let me know how you feel about the options presented above, or  
>>> feel free to propose new ones if you like. The important thing is  
>>> that we begin to gain momentum, and then keep it going forward.
>>>
>>> Thanks.
>>>
>>> N.B. For anyone who may have missed any of the discussions  
>>> reference above, please let me know and I'll be happy to forward  
>>> them to you from my archives.
>>>
>>> - ----------------------------------------------------
>>> Chris Jordan
>>> HPC Systems Engineer
>>> High End Computing Systems Group
>>> San Diego Supercomputer Center
>>> ctjordan at sdsc.edu
>>> 858.534.8347
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.1 (Darwin)
>>>
>>> iD8DBQFEKJEyPCVtcXn6kg8RArL6AJwIxZfjr0tUdIVRX8bYgYyBel+yMACgujp4
>>> BI4Q1i9d06gheHr1028BPuk=
>>> =hj2R
>>> -----END PGP SIGNATURE-----
>>>
>> Dr. Gregory Newby, Chief Scientist (Acting), Arctic Region  
>> Supercomputing Ctr
>> Univ of Alaska Fairbanks-909 Koyukuk Dr-PO Box 756020-Fairbanks-AK  
>> 99775-6020
>> e: newby AT arsc.edu v: 907-450-8663 f: 907-450-8603 w:  
>> www.arsc.edu/~newby
>
>

- ----------------------------------------------------
Chris Jordan
HPC Systems Engineer
High End Computing Systems Group
San Diego Supercomputer Center
ctjordan at sdsc.edu
858.534.8347

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEMYZlPCVtcXn6kg8RAuSPAKCDoXbruWfVJuKQqncJLtVE8rTYiwCg38TF
xPZrd6b6qgwBrBGZg5CZv4k=
=hGMM
-----END PGP SIGNATURE-----