January 2006 - ogsa-wg - lists.ogf.org

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Subramaniam, Ravi 27 Jan '06

27 Jan '06

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(a)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(a)ggf.org; ogsa-rss-wg(a)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. ]

1 0

Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Donal K. Fellows 27 Jan '06

27 Jan '06

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&category_i… 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. ]

1 0

security profiles
by Takuya Mori 26 Jan '06

26 Jan '06

Hi All, I have uploaded the sercurity profiles to the grid forge - BSP 1.0 Core https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… - BSP 1.0 Secure Channel https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… And I also updated the referenced standards sheet. https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-referenced-stand… I'd like to review the documents on the teleconference. Thanks, Takuya

2 2

Proposed agenda for Jan. 25 call
by Hiro Kishimoto 25 Jan '06

25 Jan '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Jan. 25th Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0125 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (Dec. 14 & Jan. 12) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051214/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060112/en/1 Agenda bashing 2) Basic Security Profiles final text review (60 min) Takuya has uploaded final BSPs to GridForge > - BSP 1.0 Core > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > > - BSP 1.0 Secure Channel > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > > And I also updated the referenced standards sheet. > https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-referenced-stand… > > I'd like to review the documents on the teleconference. If there is no major issue, Takuya will make final call for these profile by January 28 and will submit to GGF Editor February 4th. 3) OGSA WSRF Basic Profile Public Comment review (30 min) Review Toshinori's comment "Use of WS-I Basic Profile 1.1" > In the draft OGSA WSRF Basic Profile, the WS-I Basic Profile 1.1 [WS-I BP 1.1] > is referred to as a base specification of the profile. I have a comment on > it. > > Because the WS-I BP 1.1 does not have protocol binding specification, when using > the WS-I BP 1.1, one of the companion profiles, Simple SOAP Binding Proifle > 1.0 [WS-I SSBP 1.0] (for SOAP over HTTP binding) or Attachments Profile 1.0 > [WS-I AP 1.0] (for MIME binding) should be used. To claim conformance, conformance > claim for either WS-I SSBP 1.0 or WS-I AP 1.0 should be made in addition to > the conformance claim for WS-I BP 1.1. > > It would be helpful for users if such fact is mentioned as a guide at somewhere > in the OGSA WSRF Basic Profile 1.0. https://forge.gridforum.org/forum/forum.php?thread_id=1051&forum_id=575 4) EMS design team discussion (30 min) Continuing discussion on EMS composite roadmap document. 5) Wrap up AOB <NEXT CALL> Jan. 30 (Mon): Review of F2F minutes and action items, GGF16, GGF17, April F2F meeting plan Feb. 1 (Wed): CDDLM joint call Feb. 6 (Mon): Info model & Arch 1.5 final text review Feb. 8 (Wed): EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 -- Hiro Kishimoto

1 0

NO CALL on Monday
by Hiro Kishimoto 22 Jan '06

22 Jan '06

Hi all, Thank you very much for all of you who came to F2F meeting. We had very lively and productive meetings in Sunnyvale. As we've agreed at F2F meeting, we have NO call on Monday. Our next call is on Wednesday 25th January. Thanks, ---- Hiro Kishimoto

1 0

F2F materials
by Hiro Kishimoto 20 Jan '06

20 Jan '06

Hi Chuck, and et al, Materials for the F2F meeting should be uploaded to the following folder in GridForge. OGSA : Document Manager : Meeting Materials and Minutes : Interim Meetings : 2006 Jan interim https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… At this moment, only four materials are there. The others will be uploaded shortly. Next time, we will upload before meeting. Thanks, -- Hiro Kishimoto

1 0

REFEDS
by Hiro Kishimoto 20 Jan '06

20 Jan '06

Alan's email bounced. -- Hiro Kishimoto From: Alan Sill <Alan.Sill(a)ttu.edu> Subject: REFEDS Date: Thu, 19 Jan 2006 17:02:31 -0600 To: David Chadwick <d.w.chadwick(a)kent.ac.uk> Hi David et al., In response to your question, with no endorsement or criticism implied, see http://www.terena.nl/tech/refeds/ for information regarding the REFEDS initiative. I'm just learning about it myself. (It does include a reference however to eduroam, as we discussed.) I believe there will be further discussion of this topic among others at the next EUGrid PMA meeting (see http://eugridpma.org ). As I mentioned, I believe we need to get buy-in into the AuthZ recharter and goals process as quickly as possible, including formal representation, from such projects as Open Science Grid, the LHC Computing Grid and/or EGEE, PRAGMA, NAREGI, and other communities with an active interest in the authorization area, such as Internet2 and EDUCAUSE. I do not speak for such projects but would like to see them included... and I am excited about this prospect. Best, Alan Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU URL: http://hipcat.net/Projects/tigre ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Final proposed schedule for OGSA F2F meeting
by Hiro Kishimoto 16 Jan '06

16 Jan '06

Please accept my apologies for cross posting. Attached is the (hopefully) final proposed schedule for upcoming OGSA-WG and fellow WGs F2F meeting in Sunnyvale. The last minutes changes include; - Swap GRAAP and OGSA 1.5 on Tuesday. - Move WS-Management profile to Wed 1:30-2:30pm - Move Information to Monday afternoon, swapping with the EMS roadmap. It is also uploaded to GridForge; https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… See you in Sunnyvale! -- Hiro Kishimoto

2 3

BES container model files for Jan 16 F2F
by Ellen Stokes 16 Jan '06

16 Jan '06

Here's the files for the info model discussion on BES Container / profile. I'll post to the web site later. Ellen

1 0

Modeling guidelines doc uploaded
by Fred Maciel 14 Jan '06

14 Jan '06

Hi, I uploaded the first version of the modeling guidelines document to GridForge. It's still very preliminary. Sorry for the short notice. http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines /en/ We will review it in the face-to-face, however the objective is to have a high-level discussion if the contents (including tone, section structure, etc.) are progressing in the right direction, and what are the main pieces missing. BTW, most of the contents have already been presented and/or discussed in GGFs or OGSA face-to-face meetings and teleconferences. In the face-to-face we will also review the newer version of the information model for the container and activities, based on what was presented in a recent teleconference. See you soon, Fred Maciel

1 0