[gfs-wg] Grid File System Architecture Telecon

Tue May 24 03:31:21 CDT 2005

We will continue our discussions this tomorrow on GFS Architecture and
other GFS-WG related issues.

- Finalizing the GFS Architecture Workbook 1.0
- RNS and related issues
- Do we need a F2F before the GGF?

The telecom logistics:
The Dial in number is +1-858-678-5580.  There typically is no ringing
before the MCU answers and connects you to the call.  You should hear an
audio tone when others connect and/or disconnect. Please mention your
name and organization once you dial in.
>>  Data and Time:
>>  California: Wed 3:00 PM
>>  Chicago:    Wed 5:00 PM
>>  Boston:	    Wed 6:00 PM
>>  UK:	    Wed 11:00 PM
>>  Korea/Japan:Thu  7:00 AM

If you have VTC/Polycom at your place, let me know. We can provide the
IP number you will have to dial in from your place.

Arun

> -----Original Message-----
> From: owner-gfs-wg at ggf.org [mailto:owner-gfs-wg at ggf.org]On Behalf Of
> Arun swaran Jagatheesan
> Sent: Wednesday, May 18, 2005 12:11 PM
> To: gfs-wg at ggf.org
> Cc: Osamu Tatebe
> Subject: RE: [gfs-wg] RE: Grid File System Architecture Telecon
>
>
>
> 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
> >
>