January 2007 - tsc - lists.ogf.org

Technical Strategy Document
by David Snelling 26 Jan '07

26 Jan '07

Folks, This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows: 1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG. 2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now. 3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions. 3) Major objections at your peril. This version is changed tracked, except for the tables 1 and 3, which are all new. Enjoy. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

5 5

Re: [tsc] Technical Strategy Document
by Maguire_Tom＠emc.com 22 Jan '07

22 Jan '07

I absolutely agree that our management/deployment story must handle virtualized resources. Perhaps if we added 'management' to the bullet? And moved it down the list a bit... Maguire_Tom(a)emc.com wrote: > Page 3 (characteristics and goals) Infrastructure Virtualization > It may be a characteristic of Grids (but not a necessary one). I > don't think it is a goal either (at least w.r.t. Infrastructure). I would > remove that one. Further virtualization work is not being done > (infrastructure-wise) in OGF, storage, network and server virtualization are > all be defined, spec'd and implemented elsewhere. I put that in there, because the experience at Oracle is that virtualization of resources is a big part of the grid story expected and experienced by our customers. My intention there was mostly to try to recapture a bit of mindshare for OGF. That said, I agree that we have no business defining/spec'ing/implementing virtualization, but our deployment/management strategy must (I assert) include an understanding of managing virtualized resources. Best, chris Tom +1 (845) 729-4806 Blackberry Connect for Palm

1 0

Fwd: OGF19 TSC Report-Out session (PROPOSED DESCRIPTION)
by David Snelling 18 Jan '07

18 Jan '07

Folks, Robert proposes the following description for the TSC report out session. It looks ok to me, so send you comments directly to Gwen and Robert. Thoughts? Begin forwarded message: > From: "Fogel, Robert" <robert.fogel(a)intel.com> > Date: 17 January 2007 22:09:10 GMT > To: "Robert Cohen" <bcohen(a)bway.net>, "Subramaniam, Ravi" > <ravi.subramaniam(a)intel.com>, "Craig Lee" <craig(a)rushg.aero.org>, > "David Snelling" <David.Snelling(a)uk.fujitsu.com> > Cc: "Gwen Nichols-White" <gnwhite(a)ogf.org> > Subject: OGF19 TSC Report-Out session (PROPOSED DESCRIPTION) > > Hey Guys, Gwen has informed me that we don’t have a description in > the OGF19 program schedule for our TSC Report-Out session. Here is > what I propose: > > The purpose of this TSC (Technical Steering Committee) Report-Out > session is to report-out on the alignment gaps that exist between > the current OGF standards roadmap and the highest priority > requirements captured, rolled-up and analyzed in the previous > requirements sessions as well as the highest priority issues > captured in the previous vendor & developer adoption session. The > expected result from this TSC Report-Out session is to have a > recommended set of actions for closing the alignment gaps for the > highest priority requirements and issues. > > Does this work for you? Please comment ASAP. Unfortunately, the > deadline for submission is immediate. Thanks. > > Robert Fogel > Intel Corp, World Ahead Program, Principal Architect > OGF (Open Grid Forum) Enterprise Vice-President > 408-765-6404 > Dave's edits: The purpose of this TSC (Technical Steering Committee) Report-Out session is to report-out on the alignment gaps that exist between the current OGF standards roadmap and the highest priority requirements captured, rolled-up and analyzed in the previous requirements sessions as well as the highest priority issues captured in the previous vendor & developer adoption session. The expected result from this TSC Report-Out session is to have a recommended set of actions for closing the alignment gaps for the highest priority requirements and issues. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 1

TSC Call Wednesday, 17 January, 2007
by Joel Replogle 17 Jan '07

17 Jan '07

Here is the info for tomorrow's call: Wednesday, 17 January, 2007 11:00am-noon Central (17:00 GMT) US & Canada: 1-866-875-2241 Intl: +1-832-445-1174 Passcode: 4935596 In this week's call we will work on wrapping up the TSC document so it can be sent to "Last Call" by the end of the week, and into Public Comment just prior to OGF19. The link to the most recent version is here: https://forge.gridforum.org/sf/go/doc13748 Thanks, Joel ------------------------------------------------------------------------ ----------- Joel Replogle - Manager of Standards, Open Grid Forum replogle(a)ogf.org http://www.ogf.org

4 4

Re: [tsc] Your comments on collaboration and cluster grids
by Raeth, Peter 11 Jan '07

11 Jan '07

Chris, Your posting at http://www.ogf.org/pipermail/tsc/2006-November/000110.html is pretty interesting. DOD is committed to building net-centric systems (collaboration grids) so that data and information are available where and when needed. The creation of information from data is where a significant throughput issue lies. Data volumes are expanding at a tremendous rate, as is the complexity of algorithms used to process that data. Yet, timelines are shrinking. The expectation is that once data is collected, information should be readily available globally. How throughput plays in a collaboration grid is an interesting topic since we have traditionally thought of throughput as a "stand alone" capability. As timelines shrink, computational capability for collaboration grids is going to be needed so that, in fact, information can quickly be derived from large volumes of data using highly complex algorithms. That is why I think cluster processing grids, distributed processing grids, and other ways to provide high throughput need to be somehow integrated with collaboration grids and data center grids. What are your thoughts on that? Thanks, Peter. Peter G. Raeth, Ph.D. Research Engineer, Specialist in Adaptive Automation Ball Aerospace & Technologies Corp. Advanced Geospatial Group 2875 Presidential Drive, Suite 180 Fairborn Ohio 45324-6269 USA praeth(a)ball.com 937-320-6043 VOICE, 937-429-1687 FAX

1 0

New version Uploaded
by David Snelling 05 Jan '07

05 Jan '07

Folks, Here's what I have done to create version 9. 1) Accepted a number of edits from Ian. 2) Changed the terminology of our functional use cases, calling them instead capabilities. 3) Extracted from the OGSA Use Cases document their collection of capability requirements, see Table 1. I did a few tweaks on these to align them with our capabilities (what were before functional use cases). 4) Added a new able 3 listing all the capabilities not covered by our current simplified road map. We can expand or contract tables 1 and 3. and Table 3 needs more content before we can go to press, but this is the Gap analysis, so it should not be a problem. Next Steps: A) Joel has the pen on improving the readability of table 2. B) Chris has point on the Gap analysis, so look over Table 1 and 3 and send Chris suggestions for i - Additional capabilities for both tables ii - Content for the Specifications column of table 3. C) Sometime this week Joel will pass the pen to Chris. D) I will take the pen back on January 12 (EOD Pacific time) -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

Fwd: Notes from the TSC call
by David Snelling 03 Jan '07

03 Jan '07

Folks, Here are Joel's notes from the call. They look good to me. Thanks a good call. We should have a document by the end of the month, but there will clearly be additional versions and other documents covering non-standards activities within OGF. Oh, and one last happy new year! Begin forwarded message: > From: Joel Replogle <replogle(a)ogf.org> > Date: 3 January 2007 18:00:00 GMT > To: Dave Snelling <David.Snelling(a)UK.Fujitsu.com> > Subject: Notes from the TSC call > > Hi Dave - Here are the notes I took from the TSC call for review. > I think the main thing is the list of action steps at the end. > > Thanks, > > Joel > > ---------------------------------------------------------------------- > ------------- > Joel Replogle - Manager of Standards, Open Grid Forum > replogle(a)ogf.org http://www.ogf.org > > > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

Fwd: Archetypical Use Case for TSC Document
by David Snelling 03 Jan '07

03 Jan '07

Begin forwarded message: > From: "Franco Travostino" <travos(a)nortel.com> > Date: 3 January 2007 15:11:03 GMT > To: "Joel Replogle" <replogle(a)ogf.org> > Cc: "David Snelling" <David.Snelling(a)uk.fujitsu.com> > Subject: Re: Archetypical Use Case for TSC Document > > > Joel, > my bad. It turns out that I penciled it while in Ams still, I > turned it to Andrew for comments, and then forgot about it. I copy > Dave. Any feedback vis a vis w/ the other archetypical use cases? > Thanks -franco > >> Date: Thu, 07 Dec 2006 10:15:55 -0500 >> To: "Andrew Grimshaw" <grimshaw(a)cs.virginia.edu> >> From: Franco Travostino <travos(a)nortel.com> >> Subject: archetypical use case - application on demand >> >> >> Andrew, >> I want to align with your style of use case, I look forward to >> seeing yours . This is what I've drafted thus far for mine: >> >> c) Grid infrastructure enables efficient dissemination of >> applications. It allows the resulting ensemble of application >> instances to evolve in space and time, without any operator >> involvement. Imagine a CIO Office that needs to efficiently deploy >> an application environment across one or more data centers, which >> may be in a campus or geographically dispersed. Quite likely, this >> Office will be interested in more than one aspect of the >> application lifecycle, including: location of target recipients, >> efficient dissemination, tuning of resources allocated to >> applications, aggregation, termination. For these operations, >> virtualized application environments like virtual machines >> represent a convenient abstraction and vehicle for dissemination >> (among several implementation choices). The CIO Office expects the >> Grid infrastructure to maximize the return of investment on the IT >> assets, with value propositions in the area of high-confidence >> software distribution and aggregation, load balancing, disaster >> recovery, optimized data access, and operational efficiencies >> (e.g., fewer operators and/or smaller power budgets). >> >> thanks >> -franco > > > > > > At 09:25 AM 1/3/2007, you wrote: > >> Franco - At the Amsterdam F2F, you signed up to write an archetypical >> use case for provisioning an application on demand. The context was >> for the technical strategy document. >> >> My action was to follow up with you, and I'm only now doing that. >> Unfortunately, I should have followed up with you last month because >> the deadline for the TSC document is coming closer. My apologies for >> dropping the ball on this. >> >> We have a TSC call today (which is why I was reviewing this), so do >> you think that you can provide me with either: >> a) A first draft of the archetypical use case, or >> b) A guess at when you might be able to have a draft ready >> (understanding that sooner is better so we can get this into public >> comment by OGF19). >> >> Thanks, >> >> Joel >> >> >> --------------------------------------------------------------------- >> --- >> ----------- >> Joel Replogle - Manager of Standards, Open Grid Forum >> replogle(a)ogf.org http://www.ogf.org >> >> -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

some comments on the intro (1.3)
by Chris Kantarjiev 02 Jan '07

02 Jan '07

From Tony Dicenzo: > 1. In paragraph 2, the definition is further complicated by the possibility of the administrative domaings being heterogeneous. That raises the issue/requirement of interoperability. > > > 2.In paragraph 3....I think this unintentionally suggests Seti-at-home was the first type of grid. It wasn't of course. I suggest reversing the examples, and show Seti as a later phenomenon. Cycle stealing came well after the early grids. > > > 3. I see Qual of Service as a characteristic, but Idon't think Highest is a common requirement. Lots of academic use that doesn't demand highest. > > > 4. That list of characteristics does not seem sufficient to me to define grid. i'm not sure what is missing, but test it yourself....what is the minimum set of characteristics to define 'grid'? > > 5. I think Collaboration grids is '...OSF's long term vision'. But not necessarily that of Commercial Enterprises. > > > 6. Every IT center is a Data Center. I do not undestand how they might be different that Collab Grids. I expect a case can be made there are Data Grid. Certainly SNIA things so. > > By data center grids, do you mean grids under the control of a single Enterprise? I see you go to lengths to explain that might be misleading to say they are under the control of one administration (which I agree with). > > > 7. Not clear what a Cluster Grid is. In fact, I think this is redundant with Collab grids. The definition proposed could apply to any grid. > > > > Tony

1 0

Fwd: comments on OGF Technical Strategy document
by David Snelling 02 Jan '07

02 Jan '07

Begin forwarded message: > From: "Linesch, Mark" <mark.linesch(a)hp.com> > Date: 2 January 2007 16:04:56 GMT > To: "David Snelling" <David.Snelling(a)UK.Fujitsu.com>, "Joel > Replogle" <replogle(a)ogf.org> > Cc: <scrumb(a)ogf.org> > Subject: FW: comments on OGF Technical Strategy document > > David, Joel, > > Comments on the TSC document from Greg Astfalk at HP. Mark > > > Mark Linesch: Open Grid Forum (OGF): Hewlett Packard > 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch(a)hp.com : > linesch(a)ogf.org > > > -----Original Message----- > From: Astfalk, Greg > Sent: Saturday, December 30, 2006 7:24 AM > To: Linesch, Mark; Walker, Martin Antony (HPTC); Vickers, Paul > Subject: comments on OGF Technical Strategy document > > FWIW, in no particular order, and ranging from mega- to minutia... > > - Section 1.2 is missing a section numberin the third sentence > > - Section 1.3: "distributed computing at Internet scale" is a > poor summation. It will, for many people, eliminate the more > practical and valuable intra-organization grids. > > - Section 1.3, second paragraph implies that your focus is only on > collections of supercomputers. I certainly hope that is <not> the > case. Otherwise why did you merge with EGA, and why am I funding > OGF? > > - Section 2: the stated goal is laudable, very. However, I have > angst > over the use of "defined" (see more comments below). The clock is > ticking and 3 years is a genuinely short time-frame to get through > the process described later in the document. For me this imples > that > you need to speed-up since pushing the date out is the wrong thing > to do. > > - In some places in the document you use the construct "...text - > text..." > this should always be "...text<em-dashh>text...". That is, use the > em-dash character (Word has it) with no spaces on either side. > There > are some places where you did this. > > - The bullet list in section 2 does not have the requisite > emphasis on > "product". OGF needs to be known for more than jsut paper specs. > How do reference implementations evolve to "product"? > > - Figure 1: I assume that the union of use cases will provide the > gaps? > This should be almost known already, especially including the > commercial > space. This gors back to my point above that 2010 is an aggressive > goal. > > - OGF has a lot of WGs, some more important and relevant than others. > Is there a possiblity of re-factoring the human capital toward > meeting > the core set of WGs needed to meet your 2010 goal? I am aware that > this is volunteer stuff. > > - Section 4.3: Would this be more accurate titled if it were "Data > Movement" > > - Section 4.3: Change "...from this from this..." to "...from > this..." > > - Section 4.6: You need to add auditing to the required list, > i.e., all > three components of the so-called AAA (aka triple-A) are necessary. > > - Section 4.6.1" Tyhw work of Wenbo Mao in HPL-Beijing is, IMO, > especially useful here. It does, however, require the presence of > TPMs. > > - Section 5 in the sub-bullet list: You list "Product" and that it is > supported. By who? This goes back to my point on the word > "defined" > in your goal statement. Organizations will not be able or ready to > build operational grids without functioning code. It is > axiomatic to > me that if only paper specs exist then your goal will not be > realizable. > It is also nearly so that you can not develop "product" by > then. To > have "support" by 2010 is, IMO, impossible. Is this a solvable > conundrum? > > - Section 5: Change "Table 1 is not a complete list of OGF activity > nor..." > to "Table 1 is neither a complete list of OGF activity nor...". > You > know, the ususal neither/nor, either/or thing... > > - Section 6: A really, really good mandate. Change "All OGF document > must..." to "All OGF documents must...". > > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 1