[ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic

[A S McGough]

Hi All,

As one of the people who brought this up in the f2f I thought I should 
just bring in a few comments. My main issue with the CSG/EPS combination 
is was one of efficiency. The way it appeared to me was that the EPS 
will send a request to th CSG to provide a list of "suitable" 
candidates. Now perhaps the EPS is a dumb one which will just use the 
first one provided. In which case the time to generate the rest is 
wasted. Could someone comment/correct me on this? If there is some lazy 
way to do this then fine.

On a point which was dropped some time ago (not wanting to start an 
argument by the way), it was queried about why the BES is worrying about 
data staging when the data groups have better solutions. This is due to 
the fact that BES is using JSDL which in turn has data staging. This is 
a consequence of most existing job languages having data staging. As a 
member of JSDL (and BES) I think we can state that we will be more than 
happy to depreciate the data staging functionalities in these specs for 
better systems provided by the data groups as and when appropriate.

steve..


Andreas Savva wrote:
> Ravi,
>
> I believe the CSG suggestion is primarily for the RSS-WG to focus on
> just the normative description of the EPS interface first and not to try
> to do both CSG and EPS. CSG could still be done at a later point. I
> think we did not go as far as saying that CSG should be removed from the
> EMS architecture.
>
> But it is probably true that the need for the CSG/EPS division is not
> clear in the EMS roadmap scenarios. So I would suggest that you review
> the proposed EMS roadmap scenarios (doc in gridforge ogsa root folder; I
> can send you a url if you can't find it) and propose a scenario that
> does draw the CSG/EPS distinction out.
>
> Andreas
>
> Subramaniam, Ravi wrote:
>   
>> Hi Charles,
>>
>> Thanks for the clarification on the decision. 
>>
>> I am not sure why one would have to have policy in the domain of EPS
>> only. As far as I know, policy can be in multiple domains and
>> partitioned at multiple levels and/or hierarchically. This suggests to
>> me that one may partition policy in the CSG domain, EPS domain or any
>> such domain as one chooses. One would expect that these policy
>> frameworks be consistent but I don't see why they need to be
>> concentrated in one place.
>>
>> Second, I don't understand the motivation behind the "redo much of the
>> work". I don't see why this would be the case. It has less to do with
>> the types of services rather than the limitations of implementation. In
>> the case one cannot determine an algorithm that can have distributed
>> decision/processing or if there is some sticky performance metric then
>> one can design a software component that provides both services but
>> leverages the "tight implementation composition" in realizing that
>> algorithm. This again brings me back to the point of software component
>> versus services.
>>
>> Thanks!
>>
>> Ravi
>>
>> -----Original Message-----
>> From: Spitz, Charles F [mailto:Charles.Spitz at ca.com] 
>> Sent: Friday, January 27, 2006 1:26 PM
>> To: Subramaniam, Ravi
>> Cc: Andreas Savva; Donal K. Fellows; ogsa-wg at ggf.org;
>> ogsa-rss-wg at ggf.org
>> Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
>>
>> Hi Ravi,
>>
>> The discussion at the F2F regarding the CSG and EPS was along the lines
>> that the EPS needed more information than just a list of handles from
>> the CSG, and would most likely redo much of the work that the CSG had
>> done in putting together the candidate list.  In your example below,
>> you're suggesting that the CSG could use "policy, requirements and
>> resource properties and profiles" to generate candidate sets. The sense
>> of the F2F discussion was that policy, etc. is thought to be more in the
>> domain of the EPS. Hence the question about why CSG needs to be a
>> separate service. 
>>
>> Thanks,
>> -chuck spitz
>>
>>
>> -----Original Message-----
>> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
>> Subramaniam, Ravi
>> Sent: Friday, January 27, 2006 1:56 PM
>> To: Donal K. Fellows; ogsa-wg at ggf.org; ogsa-rss-wg at ggf.org
>> Cc: Andreas Savva
>> Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
>>
>> Hi,
>>
>> Unfortunately, I missed most if not all of the EMS sessions at the F2F
>> because of alternate commitments that I could not reschedule.
>>
>> This is the first I have seen on the suggestion to remove CSG. I would
>> strongly suggest against dropping the requirement for CSG. When view
>> from the narrow view of HPC the function of EPS and CSG has been
>> traditionally been the scheduler. There is value in this service beyond
>> the execution of jobs when we consider the larger picture of systems
>> management. There are opportunities to build candidate sets using
>> combinations of policy, requirements and resource properties and
>> profiles that go beyond the need for scheduling jobs. Such candidate
>> sets. I also agree with Donal and, based on his reference to Dave, with
>> Dave that this is an important concept and, therefore, by extrapolation
>> a service.
>>
>> This brings me to the larger topics (I don't often speak up in email so
>> please permit me to use my soap box):
>>
>> 1. What is OGSA defining: standard software components or services? The
>> granularity and the separation of concerns that is represented in the
>> concept of SOA does not preclude that services may be combined into a
>> single software component as part of implementation decisions. I see an
>> increased march in OGSA towards the implementation (i.e. software
>> components) view rather than a services view since we had the GFSG
>> direction on being more normative. 
>>
>> 2. We are increasing driving toward siloed "implementation" rather than
>> using this opportunity of such a WG to build an architecture that
>> unifies concepts that are more horizontal and integrated. EMS is
>> becoming more HPC, we have little discussion with data. We don't seem to
>> be asking questions like why should BES be worried about data staging
>> when the data team can provide more general schemes for data management
>> whether in a execution container context or otherwise. There are issues
>> that are better and much more simply handled with benefits like late
>> binding by workflows but we seem to ignore that in our current activity.
>> I am *not* finding fault but trying to raise the discussion to finding
>> the "compositional" nature of services and not biasing our thinking with
>> fitting a particular notion of an implementation. 
>>
>> 3. Taking too many shortcuts (in the name of progress) will fritter away
>> the unique opportunity that is OGSA and we will be walking the path
>> towards failure like CORBA and DCE before us (both of which had noble
>> goals but focused, from my understanding, more on the software
>> components as defined should interact as opposed to what are the key
>> functional elements and how should these interact/interoperate and be
>> composed). 
>>
>> Thanks!
>>
>> Ravi
>>
>> -----Original Message-----
>> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
>> Donal K. Fellows
>> Sent: Friday, January 27, 2006 4:26 AM
>> To: ogsa-wg at ggf.org; ogsa-rss-wg at ggf.org
>> Cc: Andreas Savva
>> Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
>>
>> Thanks to Andreas for the notification.
>>
>> Andreas Savva wrote:
>>   
>>     
>>> Even though there were no RSS-WG representatives at the F2F the EMS
>>> design team also discussed EPS and CSG as part of the EMS Roadmap
>>> session. Two *suggestions* came out of that session and should be
>>> discussed at a future joint call or perhaps during a joint session at
>>> GGF16. I think they fit in the agenda that Donal proposed below.
>>>
>>> >From the minutes:
>>> - Separation of EPS and CSG is not clearly required - suggest to RSS
>>>     
>>>       
>> to
>>   
>>     
>>> remove CSG and let them make the call. And clearly define the added
>>> value of CSG.
>>> - EPS returns an ordered (by policy) list of (Activity Execution
>>> Candidates: <JSDL doc; EPR or path of BES container; rank (optional,
>>> numeric, extensible), CDL, EPR to deployment service, ...>.
>>>
>>> Folder url:
>>>
>>>     
>>>       
>> https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor
>> y_id=1149&filtertype=basic
>>
>> I think I favour keeping the CSG as an abstract concept; it looks like
>> it will be useful for places in the Data architecture (e.g. it's
>> possibly an abstraction of other things like replica catalogs. Many
>> thanks to Dave Berry for starting me thinking about these things; it
>> helped a lot with understanding the difference between a CSG and an
>> EPS.) It will also be the level at which we describe how to map things
>> down to stuff like WSRF or WS-Transfer, since it stops us from worrying
>> about how to actually splat things over the wire in a portable way (i.e.
>> there are multiple ways of doing it, but writing connectors from one to
>> another isn't hard).
>>
>> Looking at the other issue, that of the Activity Execution Candidates, I
>> rather like much of what is suggested. I'd modify it a bit though:
>>    AEC <
>>       JSDL
>>       BES-EPR
>>       QoS Terms <
>>          Price
>>          Start Time Range[*]
>>          End Time Range
>>          etc. (extensible)
>>       >
>>       CDL (I don't know what this will look like, but having it is not a
>>            problem at all; probably easier to not require though, since
>>            as long as we have extensibility it can go in trivially
>>            anyway.)
>>       etc. (extensible)
>>    >
>>
>> Just putting the score in isn't so helpful (there's no reasonable
>> possibility of examining the provenance of the value) especially since
>> different parties that see the AEC might want to apply different
>> objective functions.
>>
>> In a reverse to things I've said in the past, I don't think we should
>> require the AEC to be implemented as a WS-Agreement template (though one
>> could be contained within it via extensibility) since that imposes some
>> very strong restrictions on how the job is subsequently handled. There
>> probably ought to be provision for the signing of the AEC, since that
>> enables the receiving party to know the identity of the party legally
>> responsible for honouring what will be the basis for a contract.
>>
>> Pricing model must itself be extensible, but lots of useful cases are
>> easily handled through "fixed amount plus <consumption level>*rate".
>>
>> Looking more at
>> https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/
>> en/1
>> I see that there are some thoughts on EPS and things more complex than
>> an atomic job. That would require some kind of composite activity
>> description language, the definition of which is outside the scope of
>> the RSS WG. (In many respects, it doesn't alter all that much anyway.
>> It's just a more complex replacement for the JSDL chunk.) Similarly for
>> scheduling parameters or parametric things (well, certainly for sched
>> parms; I don't understand the parametric world quite so well).
>>
>> Anything else I've missed?
>>
>> Donal.
>> [* Or should this be an expression of estimated delay from submission to
>>     execution commencement? Sometimes things are best one way, sometimes
>>     another. StartTime is good for reservation, StartDelay is good for
>>     immediate-execution or conventional batch queues. ]
>>
>>   
>>     
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20060129/0d5e4a0d/attachment.html