[tsc] comments from a relative newbie

[David Snelling]

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)