----- Original Message -----
> From: "ybronhei" <ybron...@redhat.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: "VDSM Project Development" <firstname.lastname@example.org>
> Sent: Sunday, December 30, 2012 1:40:03 PM
> Subject: Re: [vdsm] starting up vdsm and svdsm
> On 12/30/2012 12:11 PM, Alon Bar-Lev wrote:
> > ----- Original Message -----
> >> From: "ybronhei" <ybron...@redhat.com>
> >> To: "VDSM Project Development" <email@example.com>
> >> 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
> that if one is up the other one must also be up and serve requests.
> that case, systemd dependencies can solve the issue..
This is a dependency.
Why "the other when must also be up?"
From what I understand, there is no problem in having svdsm up anyway, hence no
If we do have mutual dependency we should work to eliminate that anyway.
> Instead of using systemd dependency and split the vdsmd service, I
> suggested to change the current relation and startup progress.
Any benefit in that over using proper system services?
> to two services that depended on each-other is another option to
> >> 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
> >> firstname.lastname@example.org
> >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> Yaniv Bronhaim.
> RedHat, Israel
vdsm-devel mailing list