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

Subramaniam, Ravi ravi.subramaniam at intel.com
Fri Jan 27 18:40:37 CST 2006 

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. ]

More information about the ogsa-wg mailing list