[gomd-devel] <DAEMON> some ideas => request for comments... ;)

[Gian Paolo Ghilardi]

Hi all.

I've some small ideas...
What's your opinion?
Any comments/suggestions?
(Feel free to add new ideas to this list or modify/update these ones.)

ID(EA): #1
CONTEXT: SCX.
PROBLEM: this facility ATM works in a serial order (calls a remote gomd,
executes the command, closes the conn then restart this sequence with
another remote gomd).
IDEA: make SCX working in a parallel way by using pthreads.
PROS: real paralellism. Launch'n Forget style.
CONS: could result difficult to be read the (mixed) outputs of remote
commands.


ID(EA): #2
CONTEXT: remote gomdSeacher (aka RGS).
PROBLEM: this facility ATM must be started manually. How to automatize this
search for clusterKnoppix & Quantian?
IDEA: as these distros start omdiscd (and we know how omdiscd works), the
/proc/hpc/nodes directory contains the nodes directories. So we can provide
a new command line option that starts immediately the search.
- The subnet searched will be the same on which local gomd is listening on
(i.e. 192.168.0.X).
- The nodes directories (==node ids) will be the host id.
- So if /proc/hpc/nodes contains 1,2,3,4 and local gomd is listening on
192.168.0.X subnet, this daemon will search the IP between 192.168.0.1 and
192.168.0.4.
PROS: this is only an option and it is targeted _only_ for users/distros
using the omdiscd daemon.
CONS: cannot be applied on systems using the flat openmosix configuration
file. Requires some polling/triggering mechanism to allow node hotplug
support.


ID(EA): #3
CONTEXT: libgtop2 support
PROBLEM: libgtop is still needed?
IDEA: now we can execute a command also on local node and we can get its
output. Why to pay extra lib costs when we can easily do (for example) a "ps
aux" and get the complete status?
PROS: remove the libgtop dependency. Daemon size will be smaller.
CONS: executing a comand to get something is not so elegant as using a a
library. Libgtop provides load value for each cpu (no other linux tool can
do this in a such easy way => top/mtop are excluded because they refresh the
state continously).


ID(EA): #4
CONTEXT: chpox support
PROBLEM: assure easy support to this  interesting too
IDEA: gomd will create a thread that does checkpoints on regular basis
(defined by the user). All migrated procs must be automagically checkpointed
on local and/or local node.
PROS: the user will be free to do his _real_ work.
CONS: we need to discuss how to implement an easy-to-use restoring facility.
FUTURE: this feature will be integrated with the future Black Hole Detection
=> if a system is gonna failure (and BHD signals this situation), gomd will
checkpoint the procs (we'll define how to do this stuff and how to choose
the important processes to be checkpointed).


Byez.

<rejected>