Re: what's the aim?

On Tue, 2 Sep 2003, Charles Forsyth wrote:

> i was hoping for a definition or at least description of what a grid might be
> in this context.  we've got a big book of grids in the office, but there must
> many different things described in it all called `grid'. (although in several
> cases it seems to be the same as what they were working on before grids
> became fashionable but with ``... for the grid'' or ``grid-oriented'' added somewhere
> presumably to get the funding).

i have read that very same book (or at least large parts of it) and it left
me puzzled too. i was only partly joking when i said 'nobody can be told
what the grid is'.

the definition that i like  most, and the definition that i'm trying to
promote, is 'distributed computation and resource sharing across 
management/administrative domains' (the definition is not mine). what is meant 
by that is that there is no single management body controlling the hardware 
and software -- everybody is free to commit resources as they see fit, and allow 
or deny access to these resources based on their own criteria. 

there are many Plan 9 installations nowadays, and 9fans are generally
generous with account sharing. so i can build a prototype grid-like environment 
by, say, allowing Dan Cross to use my nodes at University of Calgary. so he can 
import /srv/consoles from plan9.ucalgary.ca so we can have a chat server. 

this is genuine 'resource sharing' but it isn't a grid, because it requires
me to create an account for Dan on my auth server. conversely if anyone
else wants to share resources with me (Bell Labs' sources for example) they
need to create an account for me on their auth server.

> 
> what functionality, scale, etc. have you got in mind?  what's this `grid' supposed
> to do?  i understand other requirements here, such as `decentralised' for instance,
> but even then there are different strategies depending on the scale desired.
> 

i think the aim from the very beginning was to show that 'grids' (as per the
definition above) could be done easily if we have the right tools. that
there's no need for humongous 'toolkits' (hard to install, even harder to
maintain) to provide the glue on top of systems that haven't even been
designed to support networking, let alone distributed computation. 

as a joke sometime last year we (I) picked up the 'anathomy' and 'physiology'
papers and wrote a few pages of commentary highlighting the ways proposed
goals can already be achieved in plan9. and they were done some 10 years
earlier.  

now, i'm not in a position to be involved in 'gratuitous pissing off' of
people, least of all my supervisor, so i didn't push this further, except
the occasional 'but we already have that in Plan 9' remark. 

andrey

ps: a real life example of what 'may' be called a grid: my fossil died and
i spent a week waiting for a cdrom drive to arrive so i can boot the file
server and fix it. when it finally arrived and i booted from the plan9 cd i
realised that the disk contains an old distribution that didn't have the
fossil utilities at all! my solution was to connect to
sources.cs.bell-labs.com and pick them up from there. i also couldn't use
ramfs to store the configuration files for venti and fossil, because i
figured fixing everything would require several reboots, and i didn't want
to lose them. so i fired up my small 'plan9 in vmware' cluster, mounted its
kfs file system and stored the configuration files there.

that required me to have two accounts on two separate auth servers --
sources and my vmware auth. imagine a single authentication entity and we'll
have a rock-solid definition of what a grid should look like...