[gin-ops] RE: Interoperability and minimal software stack
Cindy Zheng
zhengc at sdsc.edu
Tue Mar 21 18:08:30 CST 2006
Hi, Yoshio and JP,
As JP said: "This PRAGMA <-> TeraGrid software integration
exercise is going to have it's own set of lessons that are
relevant to general grid intolerability." I agree and think
that the discussions and solutions you guys lead will be
very valuable. Could you two summarize them as one of the
lessons learned? I'll be more than happy to link it to our
GIN-ops pages. I understand that this will be a continuous
effort. We can update it as we learn more.
Let me know if I can be of any help.
Thank you,
Cindy
> -----Original Message-----
> From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> Sent: Monday, March 13, 2006 7:53 PM
> To: navarro at mcs.anl.gov
> Cc: Erwin.Laure at cern.ch; o.van-der-aa at imperial.ac.uk;
> philip.papadopoulos at gmail.com; catlett at mcs.anl.gov;
> d.colling at imperial.ac.uk; m.aggarwal at imperial.ac.uk;
> yusuke.tanimura at aist.go.jp; skow at mcs.anl.gov;
> parzberg at ucsd.edu; fplin at nchc.org.tw; mjk at sdsc.edu;
> zhengc at sdsc.edu; yoshio.tanaka at aist.go.jp
> Subject: Re: Interoperability and minimal software stack
>
>
>
> Hi JP,
>
> I believe Ninf-G documents at
> http://ninf.apgrid.org/documents/welcome.shtml
> (especially, sections 1 and 2) give enough information, but let me
> fill with correct information. For the past multi-grid experiments,
> we used Ninf-G version 2.4.0, but I'd propose to use Ninf-G 4.0.0 for
> future integration.
>
> ----------------------------------------------------------------------
> Package name:
> Ninf-G 4.0.0
>
> Availability requirements (provides the resource operator
> with hardware
> and core software and service existense requirements)
>
> # For the operating conditions, please refer Ninf-G manual section
> # 1.3.3 at: http://ninf.apgrid.org/documents/ng4-manual/overview.html
> #
> # Assumed environments (required software, etc.) are
> described in Ninf-G
> # manual section 1.7 at:
> # http://ninf.apgrid.org/documents/ng4-manual/overview.html
>
> Hardware:
> Ninf-G supports the following hardware (cpu)
> SPARC, x86, IA64, Opteron, MIPS, HP Alpha, IBM Power4
>
> Software:
> Ninf-G supports the following operating systems and compilers:
> Solaris9/gcc-2.95/Sun Compiler
> Linux/gcc-2.9.5/gcc-3.x/Intel Compiler 8.x/
> IRIX/SGI Compiler
> Tru64 UNIX (OSF1 V5.1)/Compaq C/gcc 3.x
> AIX5.2/gcc 2.9
> # Intel Compiler 8.1 is a requirement by not Ninf-G but
> # application (TDDFT)
>
> Ninf-G requires
> - Globus 2.2 or later
> For GT4:
> - GT4 Pre-WS MDS must be setup if MDS2 is needed by users
> - GT4 Information Services C bindings must be setup if
> MDS4 on C Client is needed by users
> For GT2:
> - All SDK bundles of the GT must be built from
> source bundles.
> - All SDK bundles of the GT must have a common flavor.
>
> - Python 2.3 or later
>
> Services:
> Ninf-G uses the following services for remote process
> invocation:
> Globus 2.4.3 GRAM w/ JM supporting
> JobType={single|multiple|mpi}
> Globus 4.0.x pre-WS GRAM w/ JM supporting
> JobType={single|multiple|mpi}
> Globus 4.0.x WS GRAM w/ JM supporting
> JobType={single|multiple|mpi}
>
> Security:
> Ninf-G employs GSI for security, i.e. both Ninf-G users and
> server computers need their certificates.
> Ninf-G server computers must accept a CA certificate which
> issues the user certificate. On the contrary, Ninf-G client
> computer (user's machine) must accept CA certificates which
> issue server certificates to the server computers.
>
> For example, in the multi-grid experiments using TDDFT, I asked
> ANL and NCSA to trust AIST GRID CA which issues a user
> certificate to Yusuke Tanimura (an application driver of TDDFT)
> and include its certificate and a signing policy file in ANL
> and NCSA clusters. On the other hand, our cluster in AIST
> accepted DOE Grid CA certificates and signing policy files.
>
> Network:
> No requirements for bandwidth or latency.
> Only requirement on networking is that the server (compute)
> nodes must be IP-reachable to the client machine. Thus, the
> client machine must have a public IP address. Private IP
> addresses can be assigned for compute nodes if NAT is
> available. (This is also described in Ninf-G manual section
> 1.7.3).
>
> Core modifications (provides the resource operator with the list of
> changes necessary to support this package)
> Modify core software and services:
> This is described in Ninf-G manual section 2 at:
> http://ninf.apgrid.org/documents/ng4-manual/install.html .
>
> If Ninf-G Client uses MDS 2 or MDS4, MDS setup is required on
> the gatekeeper nodes. Procedures are different between GT2 and
> GT4. Please refer Ninf-G manual section 2.3 (Installation),
> especially items titled "Registering the host information",
> "Settings for provision of Ninf-G Executable information by
> MDS2", and "Settings for provision of Ninf-G Executable
> information by MDS4".
>
> New packaged provided network services:
> Ninf-G doesn't have any.
> ----------------------------------------------------------------------
>
> navarro> Does this sound like a useful base set of details?
> Is it an overkill?
> navarro> Once we have more examples of core modification
> descriptions we may be
> navarro> able to come up with a more precise way of
> describing them, and maybe
> navarro> even eventually of packaging them.
>
> Supported hardware and software are not requirements, but supported
> platforms though we can consider these hardware/software are
> requirements by Ninf-G :-)
>
> According to my experiences on integrating Ninf-G 2.4.0 into NMI
> Release 8, the above information (supported platforms, required
> software and services, and assumed environments (e.g. security and
> network)) would be enough as a base set of details.
>
> regards,
>
> --
> Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> http://ninf.apgrid.org/
> http://www.apgridpma.org/
>
>
>
> From: JP Navarro <navarro at mcs.anl.gov>
> Subject: Re: Interoperability and minimal software stack
> Date: Mon, 13 Mar 2006 10:38:24 -0600
> Message-ID: <C532F13B-21B2-429B-A29E-0637BA28D3A8 at mcs.anl.gov>
>
> navarro> Information that I believe would be useful to have
> about a package, and
> navarro> it's dependency and core configuration requirements.
> Core configuration
> navarro> means anything that a normal user installing into a
> community software
> navarro> area couldn't do on their own.
> navarro>
> navarro> I'm using Ninf-G as an example. I'm sure the answers
> aren't correct.
> navarro>
> navarro> Package name:
> navarro> Ninf-G 2.4.0
> navarro>
> navarro> Availability requirements (provides the resource
> operator with hardware
> navarro> and core software and service existense requirements)
> navarro> Hardware:
> navarro> x86
> navarro> Software:
> navarro> Linux OS w/ glibc 2.2 or 2.3
> navarro> Intel 8.1 compiler
> navarro> Services:
> navarro> Globus 2.4.3 GRAM w/ JM supporting JobType=multiple
> navarro> Globus 4.0.x pre-WS GRAM w/ JM supporting
> JobType=multiple
> navarro> Security:
> navarro> Accept CA certificates from: x, y, z
> navarro> Network:
> navarro> Bandwidth or latency requirements if any
> navarro>
> navarro> Core modifications (provides the resource operator
> with the list of
> navarro> changes
> navarro> necessary to support this package)
> navarro> Modify core software and services:
> navarro> Modify MDS2 configuration by:
> navarro> 1. change config files x, y, z
> navarro> 2. install provider scripts a, b, c
> navarro> 3. <whatever>
> navarro> New packaged provided network services:
> navarro> Ninf-G doesn't have any I believe
> navarro>
> navarro>
> navarro> Does this sound like a useful base set of details?
> Is it an overkill?
> navarro> Once we have more examples of core modification
> descriptions we may be
> navarro> able to come up with a more precise way of
> describing them, and maybe
> navarro> even eventually of packaging them.
> navarro>
> navarro> JP
> navarro>
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Sunday, March 12, 2006 7:07 PM
> navarro> > To: navarro at mcs.anl.gov
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Hi JP,
> navarro> >
> navarro> > Thanks for the offer.
> navarro> > What should be the next step? Should I provide
> documents and/or
> navarro> > materials which describe how Ninf-G interface with
> the Globus?
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Friday, March 10, 2006 7:37 AM
> navarro> > To: Yoshio Tanaka
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Yoshio,
> navarro> >
> navarro> > I wear two hats, one is that of a a TeraGrid
> resource operator, and
> navarro> > the
> navarro> > second is that of a TeraGrid wide software
> integrator: I'm a member of
> navarro> > the team that prepares TeraGrid core software for
> TeraGrid wide
> navarro> > deployment.
> navarro> >
> navarro> > As we bridge grid-to-grid software gaps we've
> talked about using
> navarro> > community
> navarro> > software areas to store the software. As a
> software integrator I'm
> navarro> > very
> navarro> > interested whenever community software, like
> NINF-G, interfaces
> navarro> > with or
> navarro> > touches core Grid software.
> navarro> >
> navarro> > So, I'm offering my assistance in figuring out how
> to deliver the
> navarro> > pieces
> navarro> > of NINF-G, or any other PRAGMA software, that
> would require changes to
> navarro> > TeraGrid core software. This PRAGMA <-> TeraGrid
> software integration
> navarro> > exercise is going to have it's own set of lessons
> that are relevant to
> navarro> > general grid intolerability.
> navarro> >
> navarro> > Regards,
> navarro> >
> navarro> > JP
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Friday, March 10, 2006 12:50 AM
> navarro> > To: navarro at mcs.anl.gov
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Hi JP,
> navarro> >
> navarro> > navarro> > navarro> First we do need to expand the
> types of
> navarro> > applications
> navarro> > that
> navarro> > navarro> > the core grid
> navarro> > navarro> > navarro> software can support. On many
> grids MPI is not a
> navarro> > navarro> > requirement and grid
> navarro> > navarro> > navarro> software isn't built to
> support it. Perhaps MPI
> navarro> > should be
> navarro> > navarro> > added to the
> navarro> > navarro> > navarro> interoperable core grid
> software requirements?
> navarro> > navarro> >
> navarro> > navarro> > I agree that many (parallel)
> applications are written by
> navarro> > MPI
> navarro> > and
> navarro> > navarro> > Grid-enabled MPI makes them possible to
> run on the Grid
> navarro> > (cross-site
> navarro> > navarro> > run). But I'm doubtful about the
> practicality of
> navarro> > Grid-enabled MPI due
> navarro> > navarro> > to some reasons such as (1)
> co-allocation is still not
> navarro> > easy,
> navarro> > (2) MPI
> navarro> > navarro> > is poor for fault recovery, and (3) MPI
> is poor for dynamic
> navarro> > resource
> navarro> > navarro> > allocation/de-allocation/migration. I
> have no objection to
> navarro> > add MPI to
> navarro> > navarro> > the interoperable core grid software
> requirements, but it
> navarro> > should not
> navarro> > navarro> > be so easy to run MPI applications (for
> certain
> navarro> > duration) for
> navarro> > testing
> navarro> > navarro> > multi-grid interoperation.
> navarro> > navarro>
> navarro> > navarro> There may be some confusion on my part on
> your MPI
> navarro> > requirement.
> navarro> > You need
> navarro> > navarro> the JobManager to support jobtype=mpi,
> and not mpi flavored
> navarro> > Globus
> navarro> > navarro> libraries,
> navarro> > navarro> right?
> navarro> >
> navarro> > Sorry, I confused as well. mpi flavored Globus is
> not required for
> navarro> > our application.
> navarro> > For the clarification, TDDFT does not need
> jobtype=mpi. It invokes
> navarro> > multiple server processes using jobtype=multiple.
> navarro> > jobtype=mpi is required for our QM/MD application
> (the other
> navarro> > routine-basis application).
> navarro> >
> navarro> > navarro> > navarro> I was very uncomfortable about
> Ninf-G wanting to
> navarro> > modify
> navarro> > navarro> > contents of my
> navarro> > navarro> > navarro> $GLOBUS_LOCATION. As a grid
> resource operator, I
> navarro> > would
> navarro> > navarro> > never install
> navarro> > navarro> > navarro> software that modifies other
> software in
> navarro> > unspecified
> navarro> > ways.
> navarro> > navarro> > I would
> navarro> > navarro> > navarro> however been willing to follow
> a series of manual
> navarro> > steps
> navarro> > navarro> > that explain
> navarro> > navarro> > navarro> exactly what files to copy and
> modify in
> navarro> > $GLOBUS_LOCATION.
> navarro> > navarro> >
> navarro> > navarro> > Well, I understand your opinion as a
> Grid resource
> navarro> > operator.
> navarro> > navarro> > According to our recent (few years)
> experiences on
> navarro> > installing
> navarro> > Ninf-G
> navarro> > navarro> > on non-franchise Grids (e.g. TeraGrid),
> I also understand
> navarro> > that
> navarro> > navarro> > modifying contents under
> $GLOBUS_LOCATION sometimes
> navarro> > becomes a
> navarro> > high
> navarro> > navarro> > barrier for installing Ninf-G.
> navarro> > navarro> > Therefore (and due to problems related
> to performance and
> navarro> > stability),
> navarro> > navarro> > we designed Ninf-G so that MDS is not a
> mandatory component
> navarro> > and
> navarro> > navarro> > modifying MDS-related configuration files under
> navarro> > $GLOBUS_LOCATION is an
> navarro> > navarro> > optional step for installing Ninf-G.
> navarro> > navarro> >
> navarro> > navarro> > But if a user would like to use MDS for
> information
> navarro> > services,
> navarro> > Ninf-G
> navarro> > navarro> > still needs to modify some files under
> $GLOBUS_LOCATION.
> navarro> > navarro> > Unfortunately, I don't know any tricks
> for providing
> navarro> > information to
> navarro> > navarro> > MDS without modifying MDS-related
> configuration files under
> navarro> > navarro> > $GLOBUS_LOCATION.
> navarro> > navarro>
> navarro> > navarro> Modifying MDS or other component
> configurations is not a
> navarro> > problem, the
> navarro> > navarro> issue we need to be sensitive to is how those
> navarro> > modifications are
> navarro> > done.
> navarro> > navarro>
> navarro> > navarro> Less desirable is for one piece of
> software, especially one
> navarro> > that is
> navarro> > navarro> deployed in a community space for a
> subset of users, to
> navarro> > need to
> navarro> > modify
> navarro> > navarro> core configurations using a black box script.
> navarro> > navarro>
> navarro> > navarro> Preferable would be to have a manual
> recipe. The main concern
> navarro> > is that
> navarro> > navarro> as a multi-grid integrator each resource
> provider needs to
> navarro> > make
> navarro> > sure
> navarro> > navarro> that one grid's changes to core
> components don't adversely
> navarro> > affect
> navarro> > navarro> others,
> navarro> > navarro> and also that the resource provider fully
> understands and can
> navarro> > support
> navarro> > navarro> those configuration changes.
> navarro> >
> navarro> > I see. Thanks for the clarification.
> navarro> >
> navarro> > Cheers,
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Thursday, March 09, 2006 9:42 AM
> navarro> > To: Yoshio Tanaka
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Yoshio,
> navarro> >
> navarro> > On Mar 9, 2006, at 10:25 AM, Yoshio Tanaka wrote:
> navarro> >
> navarro> >>
> navarro> >> Hi JP,
> navarro> >>
> navarro> >> navarro> This is a very useful discussion to
> have, since I think it
> navarro> >> could result
> navarro> >> navarro> in some guidelines on software
> deployment across grids.
> navarro> >>
> navarro> >> Well, I like this discussion and thanks for your
> valuable commments.
> navarro> >>
> navarro> >> navarro> First we do need to expand the types of
> applications that
> navarro> >> the core grid
> navarro> >> navarro> software can support. On many grids MPI is not a
> navarro> >> requirement and grid
> navarro> >> navarro> software isn't built to support it.
> Perhaps MPI should be
> navarro> >> added to the
> navarro> >> navarro> interoperable core grid software requirements?
> navarro> >>
> navarro> >> I agree that many (parallel) applications are
> written by MPI and
> navarro> >> Grid-enabled MPI makes them possible to run on
> the Grid (cross-site
> navarro> >> run). But I'm doubtful about the practicality of
> Grid-enabled MPI
> navarro> >> due
> navarro> >> to some reasons such as (1) co-allocation is
> still not easy, (2) MPI
> navarro> >> is poor for fault recovery, and (3) MPI is poor
> for dynamic resource
> navarro> >> allocation/de-allocation/migration. I have no
> objection to add
> navarro> >> MPI to
> navarro> >> the interoperable core grid software
> requirements, but it should not
> navarro> >> be so easy to run MPI applications (for certain
> duration) for testing
> navarro> >> multi-grid interoperation.
> navarro> >
> navarro> > There may be some confusion on my part on your MPI
> requirement. You
> navarro> > need
> navarro> > the JobManager to support jobtype=mpi, and not mpi
> flavored Globus
> navarro> > libraries,
> navarro> > right?
> navarro> >
> navarro> >> navarro> I was very uncomfortable about Ninf-G
> wanting to modify
> navarro> >> contents of my
> navarro> >> navarro> $GLOBUS_LOCATION. As a grid resource
> operator, I would
> navarro> >> never install
> navarro> >> navarro> software that modifies other software in
> unspecified ways.
> navarro> >> I would
> navarro> >> navarro> however been willing to follow a series
> of manual steps
> navarro> >> that explain
> navarro> >> navarro> exactly what files to copy and modify in
> $GLOBUS_LOCATION.
> navarro> >>
> navarro> >> Well, I understand your opinion as a Grid
> resource operator.
> navarro> >> According to our recent (few years) experiences
> on installing Ninf-G
> navarro> >> on non-franchise Grids (e.g. TeraGrid), I also
> understand that
> navarro> >> modifying contents under $GLOBUS_LOCATION
> sometimes becomes a high
> navarro> >> barrier for installing Ninf-G.
> navarro> >> Therefore (and due to problems related to
> performance and stability),
> navarro> >> we designed Ninf-G so that MDS is not a mandatory
> component and
> navarro> >> modifying MDS-related configuration files under
> $GLOBUS_LOCATION
> navarro> >> is an
> navarro> >> optional step for installing Ninf-G.
> navarro> >>
> navarro> >> But if a user would like to use MDS for
> information services, Ninf-G
> navarro> >> still needs to modify some files under $GLOBUS_LOCATION.
> navarro> >> Unfortunately, I don't know any tricks for
> providing information to
> navarro> >> MDS without modifying MDS-related configuration
> files under
> navarro> >> $GLOBUS_LOCATION.
> navarro> >
> navarro> > Modifying MDS or other component configurations is
> not a problem, the
> navarro> > issue we need to be sensitive to is how those
> modifications are done.
> navarro> >
> navarro> > Less desirable is for one piece of software,
> especially one that is
> navarro> > deployed in a community space for a subset of
> users, to need to modify
> navarro> > core configurations using a black box script.
> navarro> >
> navarro> > Preferable would be to have a manual recipe. The
> main concern is that
> navarro> > as a multi-grid integrator each resource provider
> needs to make sure
> navarro> > that one grid's changes to core components don't
> adversely affect
> navarro> > others,
> navarro> > and also that the resource provider fully
> understands and can support
> navarro> > those configuration changes.
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Thursday, March 09, 2006 6:15 AM
> navarro> > To: Yoshio Tanaka
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Yoshio,
> navarro> >
> navarro> > This is a very useful discussion to have, since I
> think it could
> navarro> > result
> navarro> > in some guidelines on software deployment across grids.
> navarro> >
> navarro> > First we do need to expand the types of
> applications that the core
> navarro> > grid
> navarro> > software can support. On many grids MPI is not a
> requirement and grid
> navarro> > software isn't built to support it. Perhaps MPI
> should be added to
> navarro> > the
> navarro> > interoperable core grid software requirements?
> navarro> >
> navarro> > I was very uncomfortable about Ninf-G wanting to
> modify contents of my
> navarro> > $GLOBUS_LOCATION. As a grid resource operator, I
> would never install
> navarro> > software that modifies other software in
> unspecified ways. I would
> navarro> > however been willing to follow a series of manual
> steps that explain
> navarro> > exactly what files to copy and modify in $GLOBUS_LOCATION.
> navarro> >
> navarro> > Another perhaps even more attractive approach
> would be for software
> navarro> > like Ninf-G to keep all the MDS programs it needs
> in it's own
> navarro> > directory,
> navarro> > and then provide Grid resource operators with
> instructions on how to
> navarro> > configure their MDS deployment to call the Ninf-G
> extensions..
> navarro> >
> navarro> > I think MDS and information services is one of
> those areas that will
> navarro> > be critical for grid interoperability. We need to
> fine tune our
> navarro> > deployment and configuration processes to support
> custom information
> navarro> > service extension.
> navarro> >
> navarro> > JP
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Wednesday, March 01, 2006 11:24 PM
> navarro> > To: navarro at mcs.anl.gov
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Hello JP,
> navarro> >
> navarro> > Great! I believe TeraGrid deployed MPI(CH) meets
> needs for our QM/MD
> navarro> > simulation.
> navarro> >
> navarro> > But this is just an example.
> navarro> > In order to enable Ninf-G client to retrieve stub
> information from
> navarro> > MDS2/MDS4, some installation steps (e.g. adding
> schema, etc.) which
> navarro> > require privileges for $GLOBUS_LOCATION (e.g. user
> 'globus') are
> navarro> > necessary.
> navarro> >
> navarro> > Since using MDS2/MDS4 for information retrieval is
> optional and we
> navarro> > recommend Ninf-G users not to use MDS, these
> installation steps are
> navarro> > usually omitted. But in some cases, users may
> want to use MDS for
> navarro> > getting information. In this case, configuration
> of the core software
> navarro> > need to be changed.
> navarro> >
> navarro> > Thanks,
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Wednesday, March 01, 2006 9:24 PM
> navarro> > To: Yoshio Tanaka
> navarro> > Cc: smartin at mcs.anl.gov; grid-interop-wg at teragrid.org;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Yoshio,
> navarro> >
> navarro> > I'd be interested in drilling down into the
> specific of this
> navarro> > requirement.
> navarro> >
> navarro> > TeraGrid core software includes all of the
> following components and
> navarro> > dependencies:
> navarro> >
> navarro> > 1. mpich (gm, p4, vmi, and/or other vendor implementation)
> navarro> > 2. Globus default libraries and binaries build
> with gcc (on most
> navarro> > platforms)
> navarro> > 3. Globus vendor flavor libraries built with Intel
> 8.1 (on Linux
> navarro> > platforms)
> navarro> > 4. Globus MPI flavored libraries built with
> optimized mpi (most
> navarro> > common is
> navarro> > mpich-gm build with Intel 8.1)
> navarro> > 5. mpich-g2 built to use Globus MPI flavored libraries
> navarro> >
> navarro> > 5 depends on 4 which depends on 1.
> navarro> >
> navarro> > TeraGrid's GRAMs are already configured to use an
> optimized mpi. We
> navarro> > are also implementing GRAM extensions what will
> make it possible for
> navarro> > an mpi job to invoke an application under any
> installed MPI *without*
> navarro> > having to modify the JobManager script.
> navarro> >
> navarro> > So, is your MPI(CH) built with special
> configuration options or
> navarro> > requirements?
> navarro> > Is it possible that the TeraGrid deployed MPI(CH)
> could meet your
> navarro> > needs?
> navarro> >
> navarro> > JP
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Wednesday, March 01, 2006 9:09 PM
> navarro> > To: smartin at mcs.anl.gov
> navarro> > Cc: grid-interop-wg at teragrid.org; navarro at mcs.anl.gov;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Dear all,
> navarro> >
> navarro> > Let me add one comment.
> navarro> > Even if CSA is provided for installing necessary
> software, we may need
> navarro> > to change the configuration of core software. For
> example, assume we
> navarro> > have installed MPI(CH) by ourselves. In order to
> call the MPI(CH) as
> navarro> > backend of the GT GRAM, jobmanager script need to
> be modified.
> navarro> > If the necessary software is not completely packed
> (closed) into a
> navarro> > package, we still consider how the application
> relies on core
> navarro> > software.
> navarro> >
> navarro> > thanks,
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Wednesday, March 01, 2006 5:55 PM
> navarro> > To: smartin at mcs.anl.gov
> navarro> > Cc: grid-interop-wg at teragrid.org; navarro at mcs.anl.gov;
> navarro> > Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Stu and all,
> navarro> >
> navarro> > Yes, I agree that using the CSA for installing all
> necessary software
> navarro> > lowers the barrier for including more sites.
> navarro> >
> navarro> > Although there are anxieties such as:
> navarro> > - application developers(deployers) may expect
> underlying software
> navarro> > have been installed and may not want to install
> them by themselves,
> navarro> > - some software/middleware may need a root
> privilege and be difficult
> navarro> > to be installed by a normal user,
> navarro> > these issues will lead to R&D of middleware such
> as software
> navarro> > provisioning and virtual machine technologies.
> navarro> >
> navarro> > As Mason mentioned, PRAGMA has no concept of a
> CSA, but I think basic
> navarro> > concept and approach by PRAGMA is similar with TeraGrid.
> navarro> > Globus Toolkit is the only required software and
> for each application,
> navarro> > application driver prepares a web page on which a
> list of all
> navarro> > necessary software is described. Currently, each
> site's admin
> navarro> > installs these softwaer, but it is easy to move to
> the model of CSA by
> navarro> > providing a CSA and asking each application driver
> to install
> navarro> > the software by her/himself.
> navarro> >
> navarro> > Thanks,
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Wednesday, March 01, 2006 9:27 AM
> navarro> > To: Stuart Martin
> navarro> > Cc: grid-interop-wg at teragrid.org; Yoshio Tanaka;
> Alan Sill; Cindy
> navarro> > Zheng
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > You mention it, but it deserves reinforcement.
> Along with Community
> navarro> > Software
> navarro> > Areas, being able to discover what is installed
> and how to use it is
> navarro> > also
> navarro> > very important. If we do that right it should not
> matter that one
> navarro> > grid has
> navarro> > a particular piece of software as core and another
> has it in a
> navarro> > community area,
> navarro> > the user interface could be the same.
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Stuart Martin [mailto:smartin at mcs.anl.gov]
> navarro> > Sent: Wednesday, March 01, 2006 9:18 AM
> navarro> > To: grid-interop-wg at teragrid.org; Yoshio Tanaka
> navarro> > Cc: JP Navarro; Alan Sill; Cindy Zheng
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Comparing software stacks is interesting to know
> what grids are using
> navarro> > and learn what one *may* expect to be deployed on
> different grids.
> navarro> > But in the end, it is the grid services that are
> made available for
> navarro> > users that is of primary importance (not to
> mention being authorized
> navarro> > to use those services too :-). After that
> however, a gateway /
> navarro> > client broker / grid application developer will
> need to discover if
> navarro> > the grid software they require is installed, and
> if not, dynamically
> navarro> > deploy/build it for their communities use. It
> seems to me that that
> navarro> > is a better model than trying to create the
> perfect software stack.
> navarro> > From yesterdays discussion, I think we all were
> in agreement that
> navarro> > the notion of a Community Software Area (CSA) that
> TG makes available
> navarro> > is the way to go. Being able to discover where it
> is and an
> navarro> > understanding of how to use it will enable dynamic
> deployments. It's
> navarro> > a model that scales. Standardizing the use of
> CSAs on all grids
> navarro> > might be a next step that would give us the
> biggest bang for our buck.
> navarro> >
> navarro> > Yoshio, for the case of installing IC 8.1, if you
> are on the leading
> navarro> > edge of upgrades, then that will probably be a
> problem with most all
> navarro> > grids. So even if TG installed 8.1 for you, you
> would still be
> navarro> > prevented from using other grids if that is a hard
> requirement. If
> navarro> > you can dynamically install 8.1, then you can use
> any grid! It would
> navarro> > be nice if when you dynamically installed 8.1 in
> the CSA, that it
> navarro> > would be easy for other communities to discover
> that and use it too.
> navarro> >
> navarro> > Thoughts?
> navarro> >
> navarro> > -Stu
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp]
> navarro> > Sent: Tuesday, February 28, 2006 5:32 PM
> navarro> > To: navarro at mcs.anl.gov
> navarro> > Cc: grid-interop-wg at teragrid.org;
> Alan.Sill at ttu.edu; zhengc at sdsc.edu;
> navarro> > yoshio.tanaka at aist.go.jp
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > We should pay attention to how these software have
> been built.
> navarro> > For example, our QM/MD application needs MPICH
> compiled for F90.
> navarro> > Although this may be a past story, as prerequisite
> for Ninf-G2
> navarro> > installation, GT2 must be built from source
> bundles and all SDK
> navarro> > bundles (data, info, resource) must be built with
> the same flavor
> navarro> > (e.g. gcc32pthr).
> navarro> > # I believe we don't need to take this into
> account for GT4.
> navarro> >
> navarro> > We should also pay attention to non-grid software
> (e.g. compiler).
> navarro> > TDDFT needs Intel Compiler 8.1, which is newer
> than the default
> navarro> > version (8.0) of TG clusters. For the multi-grid
> experiment, we
> navarro> > installed IC 8.1 by ourselves.
> navarro> >
> navarro> > Thanks,
> navarro> >
> navarro> > --
> navarro> > Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
> navarro> > http://ninf.apgrid.org/
> navarro> > http://www.apgridpma.org/
> navarro> >
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: JP Navarro [mailto:navarro at mcs.anl.gov]
> navarro> > Sent: Tuesday, February 28, 2006 4:24 PM
> navarro> > To: grid-interop-wg at teragrid.org
> navarro> > Cc: Alan Sill; Cindy Zheng; Yoshio Tanaka
> navarro> > Subject: Re: Interoperability and minimal software stack
> navarro> >
> navarro> > Every TeraGrid resource has the following Common
> TeraGrid Software &
> navarro> > Service
> navarro> > "CTSS" components:
> navarro> >
> navarro> > Globus 4.0.1 gridFTP
> navarro> > Globus 4.0.1 pre-web service Gram
> navarro> > Globus 4.0.1 web service Gram with RFT and MDS4
> navarro> > Globus 4.0.1 RLS (optional, may become common)
> navarro> > Condor-G
> navarro> > Java >= Java 1.4.2
> navarro> > Apache Ant 1.6.5
> navarro> > MPI 1.2 compliant MPI
> navarro> > MPICH-G2
> navarro> > GSI OpenSSH
> navarro> > gx-map
> navarro> > MyProxy 3.4
> navarro> > tgcp 1.0.0
> navarro> > GridShell
> navarro> > Pacman 3.15
> navarro> > SoftEnv 1.4.2
> navarro> > UberFTP 1.18
> navarro> > SRB 3.2.1 client w/ includes & libraries
> navarro> > HDF4
> navarro> > HDF5
> navarro> > PHDF5
> navarro> > Kx509
> navarro> >
> navarro> > -----Original Message-----
> navarro> > From: Alan Sill [mailto:Alan.Sill at ttu.edu]
> navarro> > Sent: Tuesday, February 28, 2006 4:02 PM
> navarro> > To: grid-interop-wg at teragrid.org
> navarro> > Cc: Alan Sill; Cindy Zheng; JP Navarro; Yoshio Tanaka
> navarro> > Subject: Interoperability and minimal software stack
> navarro> >
> navarro> > As a contribution to the discussion, I include
> below the minimal
> navarro> > starting software stack chosen by the state-wide
> TIGRE project:
> navarro> >
> navarro> > Initial Software Stack
> navarro> > There will be two initial software stacks: for
> clients and cluster/
> navarro> > compute servers. The contents of the client only
> software stack
> navarro> > will be:
> navarro> >
> navarro> > Globus 4.0.1 pre-web services and web services clients
> navarro> > GSI OpenSSH client
> navarro> > UberFTP
> navarro> > Condor-G
> navarro> > The contents of the cluster/compute server
> software stack will be:
> navarro> >
> navarro> > Globus 4.0.1 pre-web services and web services
> servers and clients
> navarro> > GSI OpenSSH server
> navarro> > Additional software will be added to the software
> stacks when needed
> navarro> > by a user or a particular compute server.
> Monitoring software has not
> navarro> > been selected and may be included when the
> monitoring activity makes
> navarro> > a decision. The pre-web services portion of Globus
> 4 will be included
> navarro> > for backward compatibility. UberFTP (interface for
> GridFTP) and
> navarro> > Condor-G (adds fault tolerance and better job
> tracking) were both
> navarro> > selected for their benefits for the end user.
> Although we might not
> navarro> > use all of the components in the Globus Toolkit 4,
> we felt that it
> navarro> > was simpler to leave the unused components in the
> software stacks
> navarro> > rather than trying to remove them.
> navarro> >
> navarro> > Alan
> navarro>
>
More information about the gin-ops
mailing list