[Pgi-wg] Thoughts on the airplane home (GIN, PGI, Cycle sharing)

[Bernd Schuller]

hi Andrew,

just a few comments.

On Sa, 2010-10-30 at 18:01 +0200, Andrew Grimshaw wrote:
[...]
> Second, with respect to PGI
>
> Application deployment/management. This came across as the number one
> requirement. This came as a surprise to me, though I agree it is an
> important next step to make execution services (OGSA-BES) more useful.
> There are at least two ways to handle this problem – one I’ll call
> manual installation, configuration, and reification (MICR), and the
> other I’ll call automatic deployment, configuration, and reification
> (ADCR).
>
>
>
> MICR
>
> This is definitely the easy case.
>
> First, an application is deployed at/on a site/compute resource.
> Appropriate metadata is added to the resource metadata or an
> information service is updated with information on the local bindings
> for the executable, paths, libraries, etc.
>
> Second, once a placement decision is made by a job manager (I’m using
> the OGSA-EMS term, here think meta-scheduler), the JSDL document that
> contains an abstract application name is reified (transformed) to have
> the site-appropriate values for the application.
>
> Third, the JSDL is sent to the compute resource.
>
>
>
> I believe this is basically how UNICORE 6 does this now.
>

in UNICORE the "reification" is done directly by the execution service,
there is no need for a scheduler here.


>
>
> ADCR
>
> ADCR is similar to MICR except the deploying step of setting the
> application up and configuring the metadata is done automatically by a
> service. For simple applications – a single executable, or maybe a zip
> file that needs to be unzipped, this is easy. It can get complicated
> really fast. We at Genesis II defined a very simple deploying service
> combined with a reification service that worked for the easy case –
> executable and zip file. I can dig up the documentation on this if
> anyone is interested.
>
>
>
> I believe that the general case for this is a tarpit for a standards
> body. I have a PhD student working on it J.
>

this use case is interesting, we've also thought about this. As you say,
it gets complicated really fast :-)

[...]


> PGI profile
[...]

> My own interest is in extending the existing specs and working with
> GIN to drive spec modifications. If we go with extending the existing
> specs – BES in particular, should we modify BES just a little and
> leave the basic factory and management pattern the same? Or go with a
> cleaner model more consistent with what Bernd presented (return an
> activity handle <EPR?> and then manage the activity directly).
>

Here I have to make a correction. In fact the EMI people (specifically
from ARC and gLite) do not (yet) seem to like the "manage activity
directly" option, but want to manage all activities through a single
manager. Specific activities are "addressed" by giving the activity ID
as part of the messages. Sorry about this confusion.

I'll raise this issue with the rest of the EMI folks when we discuss the
concrete specification (wsdl/xsd). Personally I think EPRs,
WS-Addressing and separate activities are the way to go.


By the way, thanks again to you and the other PGI folks for the
constructive feedback at OGF 30.

Best regards,
Bernd.


--
Dr. Bernd Schuller
Distributed Systems and Grid Computing
Juelich Supercomputing Centre, http://www.fz-juelich.de/jsc
Phone: +49 246161-8736 (fax -8556)
Personal blog: www.jroller.com/page/gridhaus


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------