Change in vdsm[master]: Split vdsm init script into pieces

zhshzhou at linux.vnet.ibm.com zhshzhou at linux.vnet.ibm.com
Thu May 23 03:54:23 UTC 2013


Zhou Zheng Sheng has posted comments on this change.

Change subject: Split vdsm init script into pieces
......................................................................


Patch Set 3:

Thanks very much, Alon.

Here are my response to the problems.

1. About setting a environment variable to refer to the env_common.sh path, I agree with you.

2. About moving code of sourcing /etc/init.d/functions out of env_common.sh, I have a proposal. Can we consider using a --with-initd-functions=/etc/init.d/functions option in configure? We move the code of sourcing /etc/init.d/functions from env_common.sh to env-initd-functions.sh, then env_common.sh will source env-*.sh. If initd-functions is enabled, env-initd-functions.sh will be packaged and installed, so that sourced. For other distro specific things, we can also put them into env-XXX.sh, and enable it  by --with-XXX.

3. Which specific functionalities you mean to enable and to disable? Do you mean creating a small init-common function with [--background] [--pid-file=file] [--lock-file] [--respawn] options, and invoking it in init.d script, systemd service definition and Upstart job definition? This init-common function is somewhat like the "daemon"/"start_daemon" function. The env_common.sh should provide a default init-common implementation using start_daemon provided in /lib/lsb/init-functions, and as proposed in 2, if --with-initd-functions, the env-initd-functions.sh will be sourced and provides its own init-common implementation to override the default one.

4. I didn't quite catch up with your thoughts for this problem. I read the code of the patches from oVirt Engine from the links you gave me. Do you mean in different init systems, we can invoke init-common with different options? For example Upstart provides respawn and daemonize abilities already, so we can invoke init-common without --respawn and --background.

5. I believe libvirt configuration refactoring can be in future patches, not in this patch.

As regard to the limitation of hooks, yes we can not create dependency for them, but in current vdsmd.init.in we do not have the dependency calculating ability as well. Another problem I want to solve is I like the idea sourcing all the hooks into a single shell process and invoking them. Currently we run every hook in a new process. To solve these two problems, we can implement a run_tasks script to source all vdsm init tasks and calculate the dependencies, then run the tasks in the order of topological sorting. This can be done in future patches. I can accept the hook limitations in this patch.

I can submit a new patch set after we reach to an agreement.

--
To view, visit http://gerrit.ovirt.org/14826
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I0c652704000c764c6e6f248605c6a3f4f3af5ace
Gerrit-PatchSet: 3
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Zhou Zheng Sheng <zhshzhou at linux.vnet.ibm.com>
Gerrit-Reviewer: Alon Bar-Lev <alonbl at redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken at redhat.com>
Gerrit-Reviewer: Mark Wu <wudxw at linux.vnet.ibm.com>
Gerrit-Reviewer: Zhou Zheng Sheng <zhshzhou at linux.vnet.ibm.com>
Gerrit-Reviewer: oVirt Jenkins CI Server


More information about the vdsm-patches mailing list