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 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------