Hi PGI team,
- From the discussion on wednesday I understand that it is not possible to deprecate operations;
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Moreno Marzolla -Sent: Friday, May 22, 2009 12:47 PM -To: Andrew Grimshaw -Cc: 'Aleksandr Konstantinov'; pgi-wg@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
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@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) 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@pd.infn.it Phone: +39 049 8277103 -WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233 - -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg