Chris, In a chat with Mark today, we rationalized that it is unlikely that many changes are possible in the TSC Document before the end of the week. However, the opening section (1.3 in particular) seems to be important to the BoD and others. I like your thoughts here on refining the definition/attributes of different notions of Grid. Can I ask you to have a go at editing this section before the end of the week? The current version of the document is at: https:// forge.gridforum.org/sf/go/doc13748?nav=1 There trackers that capture the BoD's comments are here: https:// forge.gridforum.org/sf/tracker/do/listArtifacts/projects.tsc/ tracker.task_for_our_technical_strategy Thanks and let me know if this is simply not possible by EOD Friday. On 21 Nov 2006, at 20:29, Chris Kantarjiev wrote:
Dave,
Even though I've been working with GGF and EGA for a couple of years, my efforts have been very focused until recently - INFOD in GGF and Utility Accounting in EGA (until the last few months of EGA's lifetime, of course). I have actively ignored OGSA until a few months back.
More recently, I've been trying to get my head around OGSA and Architecture and what's needed in the merged organization - both for the sake of OGF as well as for my employer. Oracle expresses a lot of interest in (and has a fair bit of marketing success with) "grid", but the development efforts inside Oracle really don't have a lot of overlap with what's happening at OGF. My role is, not surprisingly, to try to make that overlap a bit larger, by acting on both sides.
So, I've been on all the OGSA calls lately, have tried to digest the OGSA documents and minutes, and am mostly sitting on the sidelines listening rather than trying to influence. I've been a bit more vocal on the TSC calls, of course. :-)
I'm not sanguine about things as they are, but didn't really have a good articulation of my concerns, until Paul & I had a chat yesterday. That helped crystallize some of my thinking, and is the genesis of this note. I thought it prudent to start the conversation with you - and perhaps it really should be a conversation rather than an email chain - rather than blast this into the room on some conference call...
It seems that the "let a thousand flowers bloom" philosophy of the past has produced a lot of interesting work, not all well- connected. In our brave new world of OGF, which is being called upon to produce results quickly, I think we need to come up with succinct answers to these two questions (at least):
- what is grid? - how do we get there?
I don't think we have crisp answers for either one. I'd guess that the pat answer of the moment is that the landscape document will answer the first and the strategy document will answer the second, but I really don't see that either of those answers is accurate.
For example: I've been trying to push this as an answer to "what is grid?":
- infrastructure virtualization - resource pooling & sharing - self monitoring & improvement - dynamic resource provisioning - highest quality of service
I know you've seen this before. It's not original to me - it's part of the marketing message that Oracle is using around grid, to good effect.
From a technical standpoint, I view it as the interfaces, if you will, that form the building blocks of grids, and the three types of grid that we talk about in the TSC doc are profiles that use them. But we don't have any such broad statement in any of our documents, marketing or technical, and I think that's going to cost us.
I have to admit that I nodded off while reading the outline of the landscape paper. I don't take that as a good sign. But it's also not my bailiwick, so I'm not going to worry about it.
So, let's assume that, at least among friends, we can answer the first question, even if we haven't done it crisply and for public consumption. So how do we get there?
Well, as a start, I went to look at the latest draft of the OGSA Roadmap - that seems like a good place to start. But the roadmap is really about the process for creating standards and not one for solving problems related to Grid. There is a lot of content around timetables for documents but not around what problem each of those helps you solve and how that fits into the big picture.
I'm not really sure where to go for that. The TSC document should be higher level than that; this last set of questions is tactics more than strategy.
The OGSA architecture document leaves me cold, I have to say, as does the OGSA Use Case document, which is an interesting set of ideas but refers to some documents that are very out of date (I'm thinking of its references to the OGSA Data Management Service - though I guess that's being worked on in OGSA-Data-WG). I know that these documents have a long history, and it's hard to keep them up to date and in sync.
If we were running this as an internal development project - "we" is any of us, not Oracle - there would be a clear roadmap and a timeline and Gantt charts (well, maybe not). That's admittedly harder to do in a "let a thousand flowers bloom"/"herding cats" world, but I believe that the lack of such a roadmap hurts us.
Not only because it makes it difficult for outsiders to see where we're headed, but also because it makes it difficult to see what yet needs to be done. I think I tried to make this point early in the TSC process, but didn't get very far with it - because someone pointed out, rightly, that we weren't in a position to tell people what they should be working on, since we aren't paying them.
Fair enough. But I assert that there needs to be some level of benevolent dictatorship, or, if you prefer, guidance from above. Steering the ship, or at least using the sails to take advantage of the available winds. I don't see enough of that, but maybe I don't know how to read the waves. (Maybe I'm stretching this analogy too far
Here's a case in point: provisioning and configuration management. This is of great interest to me and Oracle. I was both dismayed and encouraged to hear Andrew Grimshaw's comments at the OGSA F2F to the effect that they had looked at CDL and decided that it was too heavyweight to use (my interpretation of his words) - dismayed because it points to a lot of wasted effort, encouraged because I had reached a similar conclusion. I am merely dismayed that CDDLM- WG appears to be disbanding. Now OGF has no workable provisioning solution at all.
I feel like I'm rambling now, but I think that's the nature of the beast at the moment. But let me pose a question I don't know the answer to, and don't know how to find out, as a test case:
How does SN-CG fit into all this? Alan Yoder is hot to build something, but (famously) complained that the OGSA Data Architecture isn't something that can be built. So we've gone off and started SN-CG, which is planning to build something that is basically a GME for storage; managing storage containers (more than managing the data in the containers). I asked today how that fits into OGSA-Data, and we couldn't really get a clean answer - something that we should figure out sooner rather than later.
The next version of that question would be about provisioning and configuration management. If someone wanted to throw some provisioning and configuration management tools over the wall, what interfaces should they implement?
I could propose a set of answers here, but I'd rather get a reaction first.
Best, chris
[Bicycle crash boiler plate: I will include this boiler plate in my mails for a few weeks to apologize for terseness in the rest of the mail. I have a broken finger from the crash on Oct 4th, and typing is hard and possible only in short spurts. Sorry, Dave.] -- 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)