On 12/30/2012 12:11 PM, Alon Bar-Lev wrote:


----- Original Message -----
From: "ybronhei" <ybron...@redhat.com>
To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Sunday, December 30, 2012 11:53:17 AM
Subject: [vdsm] starting up vdsm and svdsm

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
   * when vdsm dies, svdsm will start new instance of vdsm
   automatically,
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.

Sounds like much correcter and easier to maintain design.

I am not sure I understand why these two services are related.

As far as I understand svdsm is a total stateless slave without any logic, to 
provide privilege escalation to vdsm.
Why does it need to be restarted if vdsm changes state?
I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend 
on that service.

What am I missing?

There is no relation between the states of the two. The only relation is that if one is up the other one must also be up and serve requests. for that case, systemd dependencies can solve the issue..

Instead of using systemd dependency and split the vdsmd service, I suggested to change the current relation and startup progress. Separate to two services that depended on each-other is another option to consider.


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/
I want to update it and push it forward.

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

Thanks.

--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel



--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to