Further to Gerson’s comments, the
APAC grid has addressed the problems of many exes entered into Glue, it has a
concept of “Grid-enabled” software. This is software that uses
modules and software that site’s are allowing the grid community to use.
Thus not ALL software executables end up in GLUE, only the ones a site wants to
or has been requested to support. Addressing any scaling probs
Would be nice to see such an entity
considered for the next GLUE schema
Regards
Ryan Fraser (SE)
CSIRO Exploration & Mining ,
ARRC,
Phone +61 8 6436 8760 Fax +61 8 6436 8555
From:
Gerson Galang [mailto:gerson.sapac@gmail.com]
Sent: Tuesday, 11 September 2007
10:20 AM
To: JP Navarro
Cc: Laurence.Field@cern.ch;
glue-wg@ogf.org; David Bannon;
Subject: Re: [glue-wg] Software
Packages in schema
Thanks for your response
JP,
We've done something similar to yours on the Australian Grid. We extended GLUE
1.2 by adding the SoftwarePackage entity. We're also using it in production
now. The Software entity has also been added to GLUE 1.3 but it just doesn't
have an XML implementation of the schema yet.
What we are asking the GLUE guys to consider now is to provide a way of
publishing the SoftwareExecutables that can be found inside a SoftwarePackage.
We have a few use cases for having SoftwareExecutables added in GLUE listed on
this link.. http://www.vpac.org/twiki/bin/view/APACgrid/GLUESoftwareExtension
Let's have MrBayes as an example. MrBayes usually comes with the parallel and
sequential versions of the executable. My site has named the MrBayes
sequential executable "mb-seq" and the parallel one just
"mb". Another site on the Australian Grid called their MrBayes
sequential executable "mb". It will be hard to enforce a standard
naming scheme for software executables at different sites so the only we can go
around the issue is by publishing which executables users can use if they are
running a parallel or sequential job.
We are aware that some packages might have hundreds of executables and
propagation of these info will be hard. Our plan is to provide information
about the main executables per package. Java for example has a number of
binaries in its bin directory and since java (the binary) is the mainly used
executable, we'll only be publishing this information under the
SoftwareExecutable element. Java might not be a very good example as nobody's
going to call its java binary with a different name but that's the only example
I can think of at the moment. So we are really hoping that the GLUE guys will
consider this requirement!
I also agree with you that the HandleType-HandleKey approach is a better way of
providing modules and softenv information. You can also make HandleType to have
an enumerated list of allowable values.
Cheers,
Gerson
PS.
If you are interested in seeing the software info we are publishing on the
Australian Grid...
http://www.sapac.edu.au/webmds/webmds
http://www.sapac.edu.au/webmds/webmds?info=indexinfo
On 9/11/07, JP
Navarro <navarro@mcs.anl.gov
> wrote:
Hello Gerson,
Below is an example of what TeraGrid participants currently publish
about
software. I offer it as an example/strawman of what could be added to
GLUE.
<Software>
<Name>apache-ant</Name>
<Version>1.6.5</Version>
<Default>no</Default>
<HandleType>softenv</HandleType>
<HandleKey>+apache-ant-1.6.5</HandleKey>
</Software>
TeraGrid coordinate the Name of software components, and Version formats
for a given Name so that users can compare across institutions. The
Default
attribute indicates if the software is in the default user
environment, so
users know whether they need to do anything to access the software.
HandleType and HandleKey provide information about how to access
software
that IS NOT in the default user environment. The TeraGrid has
standardized
on the SoftEnv system (HandleType=softenv) for software setup. But, this
schema was designs to accommodate other handle types, for example:
"setupscript" -> could indicate that HandleKey has
the fully
qualified
name
to an environment setup script
"modules" -> could indicated
that HandleKey is a module name
"executable" -> could indicate that
HandleKey has the fully
qualified
path
to the executable
<other options are possible>
TeraGrid informations services have been publishing this information in
production for about a month. The TeraGrid's 18 HPC resources publish
~800 Software entries and ~100 unique Name components.
There is one additional attribute we're considering for our next schema
version, a software Type or Class attribute.
Regards,
JP Navarro
------------------------------------------------------------------------
------
John-Paul
Navarro
(630)
252-1233
navarro@mcs.anl.gov http://www.mcs.anl.gov/
~navarro
TeraGrid Software
Integration Univ
of Chicago/Argonne
Nat. Lab.
GPG: 4EA9 C86B C0F0 113D 6306 98B7 3649 D6CB EFA8 4133
On Sep 9, 2007, at 6:47 PM, Gerson Galang wrote:
> Hi Laurence,
>
> The current GLUE 2.0 spec doesn't look like it can handle software
> executable information. Can you tell us if you still have plans of
> implementing that requirement in the spec?
>
> Thanks,
> Gerson
>
> On 9/3/07, Ryan.Fraser@csiro.au
<Ryan.Fraser@csiro.au> wrote:
Hi
> Laurence et al.
>
> Sorry about the delay in correspondence. I've taking a look at the
> current UCS and spec however I'm not sure that the spec includes
> some of
> APAC's concerns/UCS's. We are very interested in getting Software
> Executable information out of Glue/MDS such as that described in our
> extensions to Glue Schema 1.3. We believe that to successfully launch
> grid jobs, software info is required in addition to hardware.
>
> >From first pass, it appears that Application Environment may satisfy
> this, however with further reading I'm not sure. Can you confirm the
> element will be able to hold details such as:
> - software executable name
> - whether the executable can be run in serial OR parallel (and if so
> which parallel implementation?)
> - VO restrictions on the executable if any
>
> I noticed it can hold values for: Environment Setup, Module Name, path
> to exe etc but if you could clarify whether the above will be
> possible,
> it would be appreciated
>
> Regards,
>
>
> Ryan Fraser (SE)
> CSIRO Exploration & Mining ,
> ARRC,
>
> Phone +61 8 6436 8760 Fax +61 8 6436 8555
>
>
> -----Original Message-----
> From: Laurence Field [mailto:Laurence.Field@cern.ch]
> Sent: Friday, 13 July 2007 8:16 PM
> To:
> Cc: glue-wg@ogf.org
> Subject: Re: [glue-wg] Software Packages in schema
>
> Hi Ryan,
>
> As far as I am aware this use case has been taken into consideration.
> Please could you take a look at the use case and draft schema document
> to see if they meet your requirements.
>
> http://forge.gridforum.org/sf/docman/do/listDocuments/projects.glue-
> wg/d
> ocman.root.drafts
>
> Thanks
>
> Laurence
>
> Ryan.Fraser@csiro.au wrote:
> >
> > Hi Guys
> >
> > You'll have to excuse me; I knew to the list but have been trying to
> > monitor developments.
> >
> > I'm trying to understand whether our APAC requirements will be
> > included in v2.0. I took a brief opportunity to discuss these
> > requirements with Sergio at the OGF (not sure if he remembers) and
> > Gerson Galang has been chasing them up.
> >
> > Essentially we have identified that we'd like software package &
> > executable information available via Glue/MDS. Thus we have
> identified
>
> > the following information that we found useful:
> >
> > * Information about Software Packages install
at a site
> > * The Software Packages' corresponding
Software Executables
> >
> > Is the above catered for? If so can you point me to the correct
> > location? If not, is it too late to be considered?
> >
> > I've taken the liberty to attach our extensions on the 1.2 schema,
> > could you take a look and advise?
> >
> > Kind Regards
> >
> > Ryan Fraser (SE)
> >
> > CSIRO Exploration & Mining ,
> > ARRC,
> >
> > Phone +61 8 6436 8760 Fax +61 8 6436 8555
> >
> >
> ----------------------------------------------------------------------
> --
> >
> > _______________________________________________
> > glue-wg mailing list
> > glue-wg@ogf.org
> > http://www.ogf.org/mailman/listinfo/glue-wg
> >
> _______________________________________________
> glue-wg mailing list
> glue-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg
>
> _______________________________________________
> glue-wg mailing list
> glue-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg