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

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@ca.com] 
> Sent: Friday, January 27, 2006 1:26 PM
> To: Subramaniam, Ravi
> Cc: Andreas Savva; Donal K. Fellows; ogsa-wg@ggf.org;
> ogsa-rss-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of
> Subramaniam, Ravi
> Sent: Friday, January 27, 2006 1:56 PM
> To: Donal K. Fellows; ogsa-wg@ggf.org; ogsa-rss-wg@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@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of
> Donal K. Fellows
> Sent: Friday, January 27, 2006 4:26 AM
> To: ogsa-wg@ggf.org; ogsa-rss-wg@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. ]
>
>