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

[rbaardman]

Hi

My thoughts:

> 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.

Not a good idear, since you decided to only allow 'little' commands for SCX. So 
creating all these pthreads(wich is hard to code neatly) will be overkill and 
overhead 
to gomd imho...
Also, when a computer running gomd has only 1 CPU (wich is quite likely) the 
threads 
will be executed after each other..
-Conclusion: Please save the trouble and chance for nasty-trackable bugs :)


> 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.

Good idear! If the /proc/hpc/nodes stuff doesn't exist while using 
openmosix.map (wich 
I doubt), I think you could easily parse openmosix.map. The format is not that 
hard I 
guess. Also, we could parse /mfs, but that is not 100% sure to work (depends on 
MFS).


> 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).

Good Idear! I myself was thinking of adding extra info's based on SCX in 
java2gomd. I 
guess you could easily depend a lot of info's on SCX instead of libgtop. Since 
I just 
wrote some filtering stuff, I might be able to help if needed.


> 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).

Not a good idear. I guess you'll have to interact with the kernel or even the 
process 
to make this possible. Plus, I think gomd is more a monitoring/administrating 
daemon 
than a program interfering with the low-level oM stuff. BHD, however is a great 
thing, 
since it is "advanced monitoring" as I see it.

cheers,

Roel "roeles" Baardman

-- 
_____________________________________________________________________
Snel en voordelig ADSL nu voor iedereen bereikbaar.
Zon Breedband Budget vanaf EUR 14,95 per maand.
Nu tijdelijk geen aansluitkosten. Bestel snel op zonnet.nl/breedband