Re: [tsc] comments from a relative newbie
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)
Dave (and all), Here's a draft to replace section 1.3. I'll incorporate any feedback I get by tomorrow and check in an updated version of the document. I haven't really thought about the other sections of the opening, but I will do so. Best, chris ----------- The long-term vision of Grid can be summed up as follows: "Distributed computing across multiple administrative domains." The notion of distributed computing as used in this definition includes a wealth of highly complex technologies, some still the focus of research. This definition complicates matters further by including operation across multiple domains of administrative control. The security, privacy, economic and political aspects of Grids increase significantly with the introduction of multiple administrative domains. The concept of Grid has grown from serendipitous cycle recovery projects such as SETI@Home, to planned desktop cycle sharing via tools such as Condor, to Grids built on dedicated resources, ranging from blade servers in a corporate data center to trans-national collections of supercomputers. Our focus is on standards and tools to effectively build and utilize the last of these. We believe that Grid is composed from the following characteristics and goals: - infrastructure virtualization - resource pooling & sharing - self monitoring & improvement - dynamic resource provisioning - highest quality of service Not all of these are in every Grid, but every Grid has several of them. We find that it is helpful to use a taxonomy of different "Grids" in discussions. This is not a strict taxonomy such as used by botanists, but instead a shorthand notation that points toward a particular usage style: - Collaboration Grids. These Grids involve multiple organizations and individuals, security domains, protocols, discovery mechanisms, and heterogeneous hardware, collaborating to share their resources to make the most effective use of it for their combined user communities. This is the original and long-term vision of Grids. - Data Center Grids. These Grids are in most ways as complete technically as Collaboration Grids and involve the complete dynamic life cycle of service deployment, provisioning, management and decommissioning as part of their normal operation. At first glance, they may appear to be missing the aspect of multiple administrative domains, but that is typically an illusion. While the funding may come from a single source, and the administration carried out by a single organization, there is typically just as much tension among the various user entities as in a Collaboration Grid. For example, in the Utility Computing use case, a Data Center Grid exists inside a single Enterprise, but provides services for many individual political/security domains on an infrastructure managed with grid protocols, subject to varying service level agreements and payment schemes. This results in multiple domains sitting on top of an integrated domain, with a complex hierarchy of security constraints, resource lifetimes and performance requirements. - Cluster Grids. Aimed at high performance/throughput computing, these Grids are mostly workload scheduling environments. They tend to be less dynamically deployed and more homogeneous in their construction. Their services are either generic in nature, e.g., a job submission service, or provide the same service all the time. The provisioning decisions may be almost entirely driven by service level agreements for a fixed set of services and customers. They do not typically support the whole service provisioning life cycle. It is perhaps better to think of these (and others) as a set of perspectives, taken from different points against the same vision of Grid as a pervasive, shared, integrated platform. Much of the work of the OGF has its origins in the ongoing efforts taken from the GGF and EGA actiities. Although OGF remains open to new and innovative approaches to Grid computing, much (but by no means all) of the work outlined here has been underway for some time as part of either the "Open Grid Services Architecture" or the "Reference Model and Use Cases". These two bodies of work continue to inform and guide our strategy going forward. -----Original Message-----
From David Snelling <david.snelling@uk.fujitsu.com> Sent Mon 11/27/2006 8:38 AM To Chris Kantarjiev <CHRIS.KANTARJIEV@oracle.com> Cc TSC <tsc@ogf.org> Subject Re: [tsc] comments from a relative newbie
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?
participants (2)
-
Chris Kantarjiev -
David Snelling