[Pgi-wg] YAP - Yet Another Proposal

Sat May 23 00:09:31 CDT 2009

Hi PGI team,

>- From the discussion on wednesday I understand that it is not possible to
deprecate operations;

Well, I'm might be wrong here - but I understand from "profiling" that we
can profile elements out, e.g. one operation (which might be very close to
deprecate it).

Hence, implementations that are PGI-compliant don't need to implement these
old "profiled out" (deprecated) operations - but(!) as a consequence, are no
longer BES-compliant at this point.

However, the question arises of how much we have to profile out of BES to
meet our requirements - and if there is something left in BES then:

# New CreateActivity operation, because of immediate return of location et
al.
# get rid of management operations, because of non-needed overhead
# new state model, it seems hard to meet requirements starting from the BES
state model (work-in-progress)
# keep activity portType, but add operations that are missing in the
specification.

It seems to me now there is fairly less left of BES itself, except the name,
and even this one we wanted to change to Production Execution Service or
Advanced Execution Service (back in Geneva).

Again - a neutral observation.

Take care,
Morris

------------------------------------------------------------
Morris Riedel
SW - Engineer
Distributed Systems and Grid Computing Division
Jülich Supercomputing Centre (JSC)
Forschungszentrum Juelich
Wilhelm-Johnen-Str. 1
D - 52425 Juelich
Germany

Email: m.riedel at fz-juelich.de
Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel
Phone: +49 2461 61 - 3651
Fax: +49 2461 61 - 6656

Skype: MorrisRiedel

"We work to better ourselves, and the rest of humanity"

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), 
Dr. Ulrich Krafft (stellv. Vorsitzender)

>------Original Message-----
>-From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Moreno Marzolla
>-Sent: Friday, May 22, 2009 12:47 PM
>-To: Andrew Grimshaw
>-Cc: 'Aleksandr Konstantinov'; pgi-wg at ogf.org
>-Subject: Re: [Pgi-wg] YAP - Yet Another Proposal
>-
>-Andrew Grimshaw wrote:
>-[...]
>->>> MUST support RNS:list
>->
>->
>->>> RNS:list MUST return a predefined set of <name, EPR> pairs that
contain
>->
>->> the
>->
>->>> job information people want, e.g., session_directory, status
>->
>->
>->
>->> I would prefer to have that information profiled directly into EPR of
>->
>->> activity.
>->
>->> That would save a need to call at least one more operation for every
>->
>->> initiated Activity.
>->
>-> [Andrew Grimshaw] I'm not sure what you mean. Do you mean into the
metadata
>-> portion of the EPR? I think this may be difficult. Status information
for
>-> example changes? The contents of the session_directory may change. Or do
you
>-> have something else in mind?
>-
>-The GES must support client-initiated transfer of the input data. This
>-means that the user creates an activity in "pending" state. The GES
>-returns an activity identifier, plus additional information (e.g., a
>-URI) pointing to a location when the user can upload input data needed
>-by the activity, using a supported protocol (scp/gridftp/whatever). At
>-this point the user can start the activity.
>-
>-Thus, in the "strawman" we defined the CreateActivity operation to
>-return a structure to avoid another call to the service to get the URI
>-of the data staging area. This was considered as an implementation
>-detail, which I certainly agree. On the other hand, would we have
>-written something like "the GES must be efficient and avoid redundant
>-interactions", that requirement would have been too generic and
>-completely unverifiable, and again I would agree. I can not find any
>-succint way of describing such a requirement, suggestions are welcome.
>-
>-Anyway, this specific problem would be easy to "fix" (by another
>-profile), as the BES CreateActivity operation returns an
>-ActivityDocument datatype, which contains an extension point.
>-
>-I also see that so far the discussion focused on adding features, but it
>-would be equally important to get rid of stuff which is no longer
>-needed. For example, the BES GetFactoryAttributesDocument as defined in
>-BES makes little sense if we switch to a GLUE-based information model.
>- From the discussion on wednesday I understand that it is not possible
>-to deprecate operations; for GetFactoryAttributesDocument it is not
>-possible to have it return an empty structure, because the normative BES
>-specification says that the GetFactoryAttributesDocument operation
>-returns a FactoryResourceAttributesDocument element, which must contain
>-at least the following:
>-
>-- IsAcceptingNewActivities
>-- TotalNumberOfActivities
>-- TotalNumberOfContainedResources
>-- NamingProfile
>-- LocalResourceManagerType
>-
>-I did not check the other profiles/specifications, but I think that
>-there could be other situations in which there are features not needed
>-nor requested by GES which must be implemented anyway.
>-So, while it would be possible to extend
>-FactoryResourceAttributesDocument to include an XML rendering of some
>-GLUE information, the same structure would still contain at least the
>-abovementioned legacy stuff. Is there any way this can be avoided?
>-
>-Moreno.
>-
>---
>-Moreno Marzolla
>-INFN Sezione di Padova,    via Marzolo 8,   35131 PADOVA,  Italy
>-EMail: moreno.marzolla at pd.infn.it         Phone: +39 049 8277103
>-WWW  : http://www.dsi.unive.it/~marzolla  Fax  : +39 049 8756233
>-
>-_______________________________________________
>-Pgi-wg mailing list
>-Pgi-wg at ogf.org
>-http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090523/21774082/attachment.bin 