[glue-wg] Software Packages in schema

Ryan.Fraser at csiro.au Ryan.Fraser at csiro.au
Mon Sep 10 22:03:33 CDT 2007


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, 26 Dick Perry Ave,
Kensington, WA 6151 Australia 
Phone +61 8 6436 8760 Fax +61 8 6436 8555

 

  _____  

From: Gerson Galang [mailto:gerson.sapac at gmail.com] 
Sent: Tuesday, 11 September 2007 10:20 AM
To: JP Navarro
Cc: Laurence.Field at cern.ch; glue-wg at ogf.org; David Bannon; Fraser, Ryan
(E&M, Kensington); Paul Coddington
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 at 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 at 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 at csiro.au <Ryan.Fraser at 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, 26 Dick Perry Ave,
> Kensington, WA 6151 Australia
> Phone +61 8 6436 8760 Fax +61 8 6436 8555
>
>
> -----Original Message-----
> From: Laurence Field [mailto:Laurence.Field at cern.ch]
> Sent: Friday, 13 July 2007 8:16 PM
> To: Fraser, Ryan (E&M, Kensington) 
> Cc: glue-wg at 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 at 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, 26 Dick Perry Ave,
> > Kensington, WA 6151 Australia
> > Phone +61 8 6436 8760 Fax +61 8 6436 8555 
> >
> >
> ----------------------------------------------------------------------
> --
> >
> > _______________________________________________
> > glue-wg mailing list 
> > glue-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/glue-wg
> >
> _______________________________________________ 
> glue-wg mailing list
> glue-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg
>
> _______________________________________________ 
> glue-wg mailing list
> glue-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20070911/a2d95f84/attachment-0001.html 


More information about the glue-wg mailing list