Re: OpenMosix 2.6 Userland development

Hi Travis and others,

for some months I've started with 'om-nixus'. Unfortunately this became
too complex and unmaintainable... As replacement I've simplified my
tries and wrote some other python code. It is a complete different
approach compared with the official userspace-tools from David Santo
Orcero and Jose María Gómez - not related at all.

My daemons are just some fun with Python while trying to develop
something useful the same time. I've always liked openMosix and hope to
use/help it in the future.

For now I'm unable to test anything on a real cluster. Development takes
place on my 5 year old laptop which is not that capable of running
virtual machines. Ofcourse running an om-kernel, which is not a problem.
It is difficult to test the daemons, my random-migration lets some
processes crash. On the other hand, it also not the latest om-kernel
which should have most important bugfixes.

Anyway I hope you (or someone else) could test my efford and give some
feedback... Again, they're not related to the official openMosix
project.

If you have any questions, don't hesitate to mail me. I rarely have time
to implement more features, but replies on mail should be possible.

Hope it helps you a bit, thanks,
Niels de Vos

[ Sources in SVN, see bottom of this mail ]

--- from the README ---

Design:
One master node/process which controls process migration to other
nodes. 'omd' is the main daemon, 'omd-dumb' is run on the nodes for
sending StatusMsg and accepting/denying process migration.

'omd' asks a 'omd-dumb' to accept a process migration. The
MigrationRequest contains /proc/<pid>/stat in a dict(). This
MigrationRequest gets checked by 'omd-dumb' and a MigrationReply is
sent back to 'omd'. When the MigrationReply.accept=True, 'omd'
starts migrating the process.

When a new node (omd-dumb) joins the cluster, it sends StatusMsg-s.
The first StatusMsg is replied (by omd) with an InfoRequest. A
InfoReply is sent by the new node, which contains /proc/cpuinfo and
/proc/meminfo. The received information is stored by omd and can be
used by the Scheduler.

Parameters for omd and omd-dumb:
 -v, --verbose: enable complete logging (logging.DEBUG)
 -l, --listen=: listen on this IP-address

Status (as of $LastChangedDate: 2006-06-17 21:41:19 +0200 (Sat, 17 Jun 2006) $):
 o omd-dumb sends StatusMsg, omd adds/overwrites them in a dict
 o negotiation of process migration implemented
 o Scheduler with Simple Random Algorithm (rsched.py)
 o Scheduler contains a blacklist for stayreasons


Todo (in no particular order):
 o libomd.omCheck() with version/compatibility checking
 o format loggers nicer (show at least the name of the logger)
 o implement a smarter scheduler(s)
 o command option for scheduler selection
 o combine omd.py and omd-dumb.py into one process? Multi-Master
 o use StatusMsg.timestamp to detect dead nodes - a new thread?
 o check IPv6 support (depends main/only on Python?)


Implemented values for logging.getLogger():
 o migration
 o scheduler
 o omd
 o libomd
 o msg



--- Get the sources ---
svn co
http://nixbox.nixpanic.net/repos/dev/om-userspace/trunk/simplified

_______________________________________________
openMosix-devel mailing list
openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openmosix-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEl+hLUHyL+FAJ7UYRAkiSAJ0bpSvMh3fZ+g/V9A3VHZ1slvwY9QCg+UtU
NsUnuCIjIm845e/hSzD5UHc=
=hJFG
-----END PGP SIGNATURE-----