RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
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. ]
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. ] > >
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@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. ] >> >> >> > > >
Hi, A S McGough wrote:
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.
I think this simple scenario would not require calling the EPS; the JM would send a request to the CSG directly and use the first result. This possible interaction is mentioned in OGSA 1.0 (3.4.6.2). Btw, I didn't write this text so the people who did should comment further if the original intention was different.
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.
If this one does turn into an argument it should be taken to the BES and/or JSDL lists instead. Andreas
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
...
-- Andreas Savva Fujitsu Laboratories Ltd
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.
I think this simple scenario would not require calling the EPS; the JM would send a request to the CSG directly and use the first result. This possible interaction is mentioned in OGSA 1.0 (3.4.6.2). Btw, I didn't write this text so the people who did should comment further if the original intention was different. I'm also asking can the CSG be asked "give me the first one, I'll come back for the rest later"? In my scenario above, if you don't have something like this, then the CSG could waste a lot of time generating a
Hi, list of (potentially) thousands of resources which match my requirements when I'm going to throw away all but the first one. This could be a problem weather I'm the JM or the EPS. steve..
A S McGough wrote:
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.
I've been thinking about the difference between a CSG and an EPS for a while (funnily enough ;-) ) and I believe that the difference between them is that an EPS *is* a CSG that has been specialized for working with candidates that are execution plans. (At the moment, there is no standardized vocabulary for composite jobs - and RSS isn't defining one - so the other way of differentiating ends up with vapourware.) Given that, the main questions then become ones of how to handle efficiency and things like that. Looking at the *abstract* level, the result of a CSG is an ordered set of candidates and the result of an EPS is an ordered set of execution plans (it was decided in Boston that the EPS will not make reservations or take the final decision because that precludes scenarios involving rebooking and gets very messy indeed). The trick then is to come up with a way that allows the efficient processing of such ordered sets, but this is something where we can borrow from other standards; yes, I'm thinking of WS-Enumeration here, but you could have an OrderedSet as a WS-Resource instead, and that would work well too. The key then is for the producers of these ordered sets to implement themselves in such a way that they can do so efficiently, especially when they are producing very large candidate sets, but that is outside the domain of the standard. I've no intention of prescribing an implementation strategy... Given that (which all feels quite workable to me) the major remaining issue is what to put in the Candidate Execution Plan document, and that is something where the things that have been discussed earlier in this thread are greatly valuable. Also note that by keeping the CSG abstract on the nature of the candidate documents, it means that the concept is nicely reusable in other contexts. I do remember Ravi's cases on patch management, and Dave Berry's thoughts on how the CSG is very much like things that are in (or going to be in) the OGSA-D work. It feels like a nice synergy, and I like how it may be possible to reuse things outside EMS.
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.
As the author of (the first version of) that straw-man, if anyone has anything better to put in place of the noddy data-transfer stuff that is in there, please feel free to make a concrete suggestion. Only real requirement is that it must fit the concept of JSDL as a template document, so substituting a service in there is going to be a bit clunky; though a reference to a service could work, it's probably easier to name the data itself as a resource (using the W3C sense of the "R" word there). You can do an amazing number of things with IRIs after all (data: and cid: being distinctly interesting, though abstract URNs have many possibilities too when you add some kind of resolver, e.g. a replica catalog.) Donal.
Donal K. Fellows wrote:
A S McGough wrote:
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.
I've been thinking about the difference between a CSG and an EPS for a while (funnily enough ;-) ) and I believe that the difference between them is that an EPS *is* a CSG that has been specialized for working with candidates that are execution plans. That would work for me, and would make logical sense.
steve..
(At the moment, there is no standardized vocabulary for composite jobs - and RSS isn't defining one - so the other way of differentiating ends up with vapourware.) Given that, the main questions then become ones of how to handle efficiency and things like that. Looking at the *abstract* level, the result of a CSG is an ordered set of candidates and the result of an EPS is an ordered set of execution plans (it was decided in Boston that the EPS will not make reservations or take the final decision because that precludes scenarios involving rebooking and gets very messy indeed). The trick then is to come up with a way that allows the efficient processing of such ordered sets, but this is something where we can borrow from other standards; yes, I'm thinking of WS-Enumeration here, but you could have an OrderedSet as a WS-Resource instead, and that would work well too. The key then is for the producers of these ordered sets to implement themselves in such a way that they can do so efficiently, especially when they are producing very large candidate sets, but that is outside the domain of the standard. I've no intention of prescribing an implementation strategy...
Given that (which all feels quite workable to me) the major remaining issue is what to put in the Candidate Execution Plan document, and that is something where the things that have been discussed earlier in this thread are greatly valuable.
Also note that by keeping the CSG abstract on the nature of the candidate documents, it means that the concept is nicely reusable in other contexts. I do remember Ravi's cases on patch management, and Dave Berry's thoughts on how the CSG is very much like things that are in (or going to be in) the OGSA-D work. It feels like a nice synergy, and I like how it may be possible to reuse things outside EMS.
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.
As the author of (the first version of) that straw-man, if anyone has anything better to put in place of the noddy data-transfer stuff that is in there, please feel free to make a concrete suggestion. Only real requirement is that it must fit the concept of JSDL as a template document, so substituting a service in there is going to be a bit clunky; though a reference to a service could work, it's probably easier to name the data itself as a resource (using the W3C sense of the "R" word there). You can do an amazing number of things with IRIs after all (data: and cid: being distinctly interesting, though abstract URNs have many possibilities too when you add some kind of resolver, e.g. a replica catalog.)
Donal.
participants (4)
-
A S McGough -
Andreas Savva -
Donal K. Fellows -
Subramaniam, Ravi