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

[Philipp Wieder]

Hi Donal,

Donal K. Fellows wrote:
> 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.)
I would just say that there are cases where the existing CQP elements
will not fulfil the requirements people have. As in our case (which is,
for the time being, not really "advanced", but just a bit different),
where we just have different requirements concerning the "how long it
will take" attributes. Our intention is to achieve interoperability
between schedulers and we would like to use a some description for the
scheduling related attributes (or QoS, if you want). And we would like
to ship it together with an EPS request as well as WS-Agreement, e.g,
therefore we think going for something which can live in both (and
potentially other) specs would be good. But as you said, there is an
extension point. The only problem for us is, that the CQP elements are
mandatory for the EPS case and will collide with our time-related
attributes ...

Adios, Philipp.
>
> 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.
>