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.
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.
----- Original Message -----
From: "ybronhei" ybronhei@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?
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
On 12/30/2012 12:11 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "ybronhei" ybronhei@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
----- Original Message -----
From: "ybronhei" ybronhei@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.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" ybronhei@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..
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 mutual dependency.
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?
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
On 12/30/2012 01:45 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "ybronhei" ybronhei@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.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" ybronhei@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..
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 mutual dependency. If we do have mutual dependency we should work to eliminate that anyway.
right, svdsm can be up anyway.. but must be up and serve to let vdsm to be operational. and we can solve that by normal systemd dependency, as vdsm will require svdsm service and run it in type=forking (this way we guarantee that the parent exists and runs before starting).
I don't see any other mutual dependency between the two..
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?
Maybe not.. just need to consider differences between systemd and initctl (upstart) dependencies mechanism if we decide to rely on system services. And they work quite different..
If we don't want to have 2 implementations for that as we have now with some if-else statements in vdsmd.init script, it might help to keep it in one service that splits to 2 processes..
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
----- Original Message -----
From: "ybronhei" ybronhei@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Sunday, December 30, 2012 2:28:45 PM Subject: Re: [vdsm] starting up vdsm and svdsm
On 12/30/2012 01:45 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "ybronhei" ybronhei@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.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" ybronhei@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..
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 mutual dependency. If we do have mutual dependency we should work to eliminate that anyway.
right, svdsm can be up anyway.. but must be up and serve to let vdsm to be operational. and we can solve that by normal systemd dependency, as vdsm will require svdsm service and run it in type=forking (this way we guarantee that the parent exists and runs before starting).
I don't see any other mutual dependency between the two..
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?
Maybe not.. just need to consider differences between systemd and initctl (upstart) dependencies mechanism if we decide to rely on system services. And they work quite different..
If we don't want to have 2 implementations for that as we have now with some if-else statements in vdsmd.init script, it might help to keep it in one service that splits to 2 processes..
The problem is that we keep the same vdsmd.init for both... Usually it is best to maintain the minimal script which is distribution dependent, and having it calling some common script. For example if we port to debian, we probably need to do that anyway. So best doing that earlier than later...
The init.d vdsmd script can start the svdsm and then call the common script, the systemd can just delegate calls.
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
-- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187
vdsm-devel@lists.fedorahosted.org