draft RFC: "umbrella"

["David L. Nicol" <david@kasey.umkc.edu>]

Just think how much fun the graphics people will have with penguins
with umbrellas.


1: 

The umbrella framework can be implemented as a mounted file system,
or it can be implemented as one or more demons that monitor a set of
files or pipes.  Although a more direct syscall type of interface may
be available, the portable interface, which must be supported for a system
to claim "compliance" is all file interface based.

the framework can be inserted anywhere into the FS, for instance 

	mount /opt/umbrella/initscript /umbrella -t umbrella

or
	/opt/umbrella/takedir /umbrella

would both amount to defining umbrella with a target directory of /umbrella.

Each service is either a wservice, that you write to, or a rservice,
that you read from, to allow fully functional prototyping with fifos.


2:


At initialization time, umbrella creates a nodes/ directory w/in the
target directory, and a meta pipe within the target directory too. Each
defined node will be represented as a directory under nodes, for instance
/umbrella/nodes/fred/ or /umbrella/nodes/3/ .  The contents of the per-node
directories is defined by the specific service, or by attribute=value commands.

3:

Umbrella configuration directives are given to umbrella by opening ./meta
for writing and writing them to it.  Security is by capability keys which are
generated any time a change is made, or by permission bits, but capabilities
are be preferred because permission bits are so easy to fake in cluster situations.

Initially defined directives include:


configure and deconfigure nodes:

	add <node-name> [keyfile=filename to write a key for this node to]
		[<attribute>=<value>].....

	del[ete] <node-name> [key given at node addition]


configure per-node services

The service programs will receive the complete path to the service as
their first command-line argument.  When a per-node service is 
configured, a <service-name>.lock file appears in the target directory
for optional flock synchronization.

	wser[vice] <service-name> <path to program to run when
				   service-name is invoked, by writing
				   into it>

	rser[vice] <service-name> <path to program to run when
				   service-name is invoked, by reading
				   from it>


configure per-cluster services

These services appear in the target directory rather than each node directory.

	cwser[vice] <service-name> <path>
	crser[vice] <service-name> <path>

Extend the language of what you can echo > /umbrella/meta

	define <keyword> <path to handler>


Capability management:

Keys are random strings of alphanumerics.  

Resources are anything a system using umbrella capabilities wants
to name.

Result is either "0\n\0" or "1\n\0"

	copy <key> <path to file you will write the new key with
			single-use ability to represent what <key>
			can do >

	new <resource_name> <path where new long-term key goes>

	check <resource_name> <key> <path where result goes>	


Project Coexistence:

	As long as multiple projects do not use the same
names for either resources or services, they can coexist under the
same umbrella.  For instance, someone who is porting MOSIX from
procfs to umbrella might want to change the name of the "status"
service to something like "mstatus."	  It is hoped that as 
different projects are ported to this framework, ones that provide
similar -- fully replacement of each other -- services will give
their services the same names and the same access languages, for
drop-in replacement.



Have I left anything out, that really is common to everything?








-- 
                      David Nicol 816.235.1187 dnicol@cstp.umkc.edu
  He who says it's impossible shouldn't interrupt the one doing it.


Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/