[gfs-wg] RE: Grid File System Architecture Telecon

Arun swaran Jagatheesan arun at sdsc.edu
Wed May 18 14:10:45 CDT 2005


There is no Telecon today. There will be one next week - I am trying to
have the telecon bi-weekly. As part of this week's GGF-GFS (home) work,
we will continue with our discussions - It is a progress that we are
discussing this abstract document before we proceed with the technical
details (which could need more discussions). We can further continue
these discussions over the mail and use the Telecon to confirm a
resolution on how to proceed further.


Here are the issues raised for discussion:

 - Overloaded usage of the word "Namespace":
Osamu has mentioned about the usage of the terms like "logical
namespace, logical resource namespace, federated logical resource
namespace, .... etc.".
RESOLUTION: I will find out all the occurrences of the word "namespace"
and make sure they are not overloaded. I agree with Osamu that the
document and WG has to be consistent in naming. It is possible that we
are used to different connotations for the same word - so this also will
be a good exercise. The Glossary could help us all to be on the same
page.  Let me know if there is any suggestions or comments on the
existing Glossary.

 - Non-Webservice client (Figure 4, page 9 and 5.2.7)
As part of the Architecture three forms of clients are suggested (Figure
4). The GFS-WG currently works only on standardizing the services-based
client. One issue that was raised in last week's telecon and also in
Osamu's mail is the use of non-Webservice based client software or
protocol. We need to discuss this.
My opinion: There is no resolution yet from a WG-community perspective.
I am providing my opinion here based on my interaction with our users.
Currently, most users need the GFS-like system. It will be a restriction
to enforce the users (of any vendor implementation) to use only
service-based interface. The GFS is a good thing - but it should NOT be
about just one interface. Users should have the flexibility to take
advantage of the GFS from any interface. Figure 4 mentions the
possibility of using the GFS from existing FS-client protocols,
WS-Service client protocol and a new GFS-non-WS-client protocol. Our WG
currently is working only on the WS-Service client protocol. If and how
this new GFS-non-WS client protocol can be made a recommendation might
have to be discussed.

 - Functionality of the GFS Server (Figure 4, page 9)
Yes it was left abstract - but seems to be too abstract. The GFS Server
services the GFS-related requests from the GFS clients. As of now we
expect it to respond only to XML based requests. This server has access
to the metadata information from GFS-namespace and mapping to the
Traditional FS namespace (where the data is really located). It can also
initiate the operations that can be performed on the GFS-Namespace.
Implementers could use different ways to store and manage meta-data that
has to be accessed by the GFS Server.


 - Summary of existing or ongoing software
Yes. Can we add this as a one page document in the appendix? Since it is
difficult for one person to survey all the efforts and write about them,
can we have this done by individual contributors. Any implementer
(institution or vendor) who has some similar effort could make a one
page document about their overall architecture which could be added to
this workbook. Will one page in appendix be fine to describe the whole
system (from an architecture perspective)?

 - Last Telcon
The last week's telecon was mostly about the importance of non-WS client
protocol. A generic overview of status of the GFS was discussed. As we
are discussing it again here, you did not miss much


Cheers,
Arun

> -----Original Message-----
> From: owner-gfs-wg at ggf.org [mailto:owner-gfs-wg at ggf.org]On Behalf Of
> Osamu Tatebe
> Sent: Thursday, May 12, 2005 9:10 PM
> To: gfs-wg at ggf.org
> Subject: Re: [gfs-wg] RE: Grid File System Architecture Telecon
>
>
> Hi All,
>
> Unfortunately I also could not attend to the teleconference, but here
> is my comment to the document.
>
> * 1.1 Background
>
> The first second paragraphs said the importance of logical resource
> namespace, on the other hand, there is no explicit description
> regarding relationship with Grid File System Services and the
> namespace.
>
> Also, in this document, several terms are used for namespace; logical
> namespace, logical resource namespace, federated logical resource
> namespace, ....  We need to define this term by referring to the RNS
> document, and use consistently.
>
> * Section 4.5 Standard Interfaces
>
> I believe it is better to remove this section because this produces
> huge confusion and misleads people.  At first, the interface to be
> standardized is a service interface not a client interface.  This
> point needs to be clarified.  Moreover, I cannot find the description
> about GFS Server depicted in Figure 4.  What functionality is assumed?
> This is much important to be described in this document, I believe.
>
> For further discussion of GFS architecture, I suggest to summarize
> architecture of existing and ongoing software.
>
> Thanks,
> Osamu
>
> >> On Thu, 12 May 2005 09:08:43 -0700, Manuel Pereira
> <mpereira at us.ibm.com> said:
>
> >> Hello All,
> >> We will initiate the telecon discussions on the GFS Architecture
> >> Workbook (attached document) this Wednesday.
>
> >> Unfortunately I was not able to make the call due to a
> conflict in scheduling
> >> with an OGSA-WG meeting (3:00-4:30PM PDT) I had to attend
> to provide a monthly
> >> report on the new OGSA-Naming WG and associated progress with RNS.
>
> >> Will someone be sending out the minutes of the meeting?
>
> >> Thank you,
> >> Manuel Pereira
> >> ===============================
> >> IBM Almaden Research Center
> >> ===============================
> >> 650 Harry Road, San Jose, CA 95120
> >> 1-408-927-1935 [T/L 457]
> >> Pager: 800-946-4646 1492425
> >> http://mvp3.almaden.ibm.com
> >> mpereira at us.ibm.com
>





More information about the gfs-wg mailing list