[ogsa-rss-wg] [GSA-RG] CandidateQualityProperties

[Donal K. Fellows]

Alexander Papaspyrou wrote:
> 2007/11/23, Philipp Wieder <philipp.wieder at udo.edu>:
>> Ariel and I are currently meeting to progress with GSA and I had a quick
>> look at the current OGSA-RSS document. The CandidateQualityProperties
>> contain a number of attributes which are also of interest for us in a
>> scheduling context, but for our needs there are a number of other things
>> we would like to add. Is the current set of CandidateQualityProperties
>> fixed and should we use the extension point to add our own stuff? Or do
>> you plan to replace this sooner or later by a more generic QoS construct?
> 
> I would vote for splitting this out from RSS.
> 
> See, at least the timing constraints are something that is probably
> needed by several different actors within the whole process: users
> want to define start times, deadlines, and the like (probably using
> JSDL), brokers need to know about the constraints for planning
> (affecting GSA and RSS), and maybe LRMSs want the information for
> being allowed to kill the job if it exceeds its runtime estimation
> (think into the direction of BES/DRMAA).
> 
> Supposedly, this also goes for other properties described in the CQPs.
> 
> However, this is just my opinion and totally uncoordinated with the
> writer's thoughts.
> 
> So, what do you think, Donal?

The content of the CQP element is a feature of the Execution Planning
Service and represents what I think is the minimal set of non-functional
information required to make a decision on what candidate is best for a
particular usage. The information that they convey is about "how long
will it take" (in various senses) and "what will it cost me" (which
really is just as nasty as it appears, except in very limited cases).
I also suspected that the bits I'd thought of weren't enough for more
advanced cases, so I left as an extensibility point. (In general,
candidates that are not related to execution planning would use totally
different types of CQPs, of course. Data, for example, has many kinds of
non-functional quality parameters.)

Going forward, we might or might not spin out the EPS CQPs, though I
plan to keep the CQP container element as it is. After all, it's just a
box where you can fill things in. :-) I'd imagine that in a practical
implementation the JSDL would need rewriting to include information in
order to get a particular QoS; that lies completely outside the scope of
RSS anyway (i.e. I expect it to be either someone else's problem or
system-specific).

If we spin out, I'd hope that whoever we spin out to would consider them
to be a submission of things that are important. :-)

Donal.