[Pgi-wg] YAP - Yet Another Proposal

[Moreno Marzolla]

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