Currently, vdsm deamon script starts (respawn) vdsm process as vdsm
user, and during that vdsm starts super vdsm process as root.
 * when vdsm dies, svdsm process supposed to notice and exit by itself.
 * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to
start new svdsm instance after verifying that old instance is dead and
call it.
This is super vdsm and vdsm startup design in general.
--


In current implementation we have some edge cases that we need to handle:
 * vsdm can try to communicate with old instance of svdsm.
 * vdsm can kill wrong process that got last svdsm pid before starting
the new instance of svdsm.
 * vdsm can try to communicate with svdsm before svdsm starts to serve
requests.
And i guess there are many more possible senerios that can cause bugs..

As it seems, it doesn't make sense that vdsm manages root process, and
can kill it..

What if svdsm will be the manager of vdsm:
 * deamon script starts up svdsm instance instead of vdsm
 * svdsm forks vdsm and changes its privilege (uid to vdsm)
 * vdsm receives as parameter svdsm pid for sudo requests
you mean vdsm can kill svdsm? I'd suggest svdsm exports a 
getProxy().killSvdsm() functinon.
 * when vdsm dies, svdsm will start new instance of vdsm automatically,
supervdsm poke should be change to periodically wait() and restart.
and note the crash reason to syslog.
 * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its
son process, and another instance of svdsm will start automatically and
start new instance of vdsm.
usecase: svdsm recieve SIGTERM,
(1)if svdsm waits to join vdsm in a thread:
   vdsm as its child process should receive signal to terminate,
Using Process() to start vdsm, and if supervdsm reload SIGTERM(sigterm handler 
is to kill vdsm), supervdsm will never join vdsm and exit.It will just hang 
there.

(2)when svdsm not wait:
   vdsm still be alive,svdsm will need to kill vdsm at next time startup or 
will result in:
error: [Errno 98] Address already in use when start a new vdsm to bind xmlrpc 
server

also, Not sure about if it is safe for svdsm to terminate vdsm because vdsm may 
in the middle of other activities.

Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm
user (check log permissions, clean old temporary files and so on if
needed..)

Royce Lv has already started to work on such design here
http://gerrit.ovirt.org/#/c/4145/

So my previous choice is to :
1) As root, create a new process for supervdsmServer
2) Drop privileges in the parent
3) Start vdsm in the parent

Then, if vdsm detects a problem with supervdsm, it can just exit.  This will 
cause respawn to restart
everything again.  So if either process (vdsm, or supervdsm) dies, the whole 
thing will be respawned.

See the draft here, let's discuss about it:
http://www.ovirt.org/Normalize_vdsm_start_up_process

I'm also agree with breaking these two as dependent services just as vdsmd and 
libvirtd. These will involve supervdsm died
and vdsm reconnect, if we use key this will be security issue. So now we use 
key as local variable.If just use child/parent
pipe, here is similar restart logic to handle.

I want to update it and push it forward.

I would like to hear more opinions and point of views on this change,

Thanks.




_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to