CP-51870: Refresh toolstack services #6060
Conversation
|
The odd thing about xe-toolstack-restart is that is stops and starts services in the same order, whereas it'd better do the restarts in the opposite order. Otherwise you can't really reason about dependencies at all... Even better may be to have a single "toolstack" service that depends on all of these individual services and restart just that, hoping that systemd would stop and start them things correctly based on dependencies encoded in the service files (as a single |
|
Also, your branch is out of date, and you are missing some new rrdd plugins. |
It looks systemd can figure out the right order to start the service, so start order does not matter. Yeah, one toolstack service configure the depends, and just let systemd decide the order sounds a better solution. |
liulinC
changed the title
|
Converted this to draft. This needs to be thought trough and brought up to date before it will be considered for merging. My preference would be for start and restart the sequence being controlled by systemd but this requires testing that dependencies are correct. |
Yeah, I am considering how to use systemd to manage it and got a roughly plan. |
liulinC
force-pushed
the
private/linl/dev
branch
from
c4985f3
to
bd70235
Compare
liulinC
changed the title
services configuration Systemd services has good support for the services depends and orders in the Unit file, that is the place the restart order should be stated. However, the command `systemd stop foo bar ...` will override the order in the Unit file. As the number of the services grow up, it is really hard to manage the order in the systemd command In order to resolve the issue, `toolstack.target` is created to group and manage the toolstack services. - toolstack.target: `Wants: foo.service` will start foo.service when `systemctl start toolstack.target` - foo.service: `PartOf: toolstack.target` will restart/stop foo.service when `systemctl stop/restart toolstack.target` Note: Above two does not have to match, eg. if we do not want to start a service during `systemctl start toolstack.target`, we can remove it from the first list. - Following xenopsd services are no longer valid, just got removed * xenopsd * xenopsd-xenlight * xenopsd-simulator * xenopsd-libvirt Signed-off-by: Lin Liu <[email protected]>
liulinC
force-pushed
the
private/linl/dev
branch
from
bd70235
to
af2c430
Compare
|
test result refer to xapi.spec repo pull request. |
Yes, XenRT detect a problem so I update |
|
The change to use a systemd target looks great, thanks for doing it. As discussed elsewhere, it would be better to include the target file in this repo. Otherwise, I think a difference between old and the new may be that if any of the services fail to start, now xe-toolstack-restart would not raise an error? At least that is how |
Note: the for loop reverse the TO_RESTART order