About vdsmd init script
by zhshzhou＠linux.vnet.ibm.com
Hi,
I'm working on making VDSM run on Ubuntu. The current work item is to
start vdsmd service on Ubuntu. After discussion with Alon Bar-Lev on one
of my patches [1], I come up with an idea. I would like to listen to
other developers' suggestions before submit a new patch set.
Firstly the vdsmd.init.in should be split into pieces. I move the
initialization operations out of vdsmd.init.in, and put them in
respective scripts, for example,
init_00_shutdown_conflicting_srv.sh
init_04_gencerts.sh
init_08_libvirtd_sysv2upstart.sh
init_12_libvirtd_reconfigure.sh
init_16_start_needed_srv.sh
...
init_48_tune_system.sh
Then I can write a master script named init_common.sh. The
init_common.sh provides some environment variables and common functions,
it sources init_*_*.sh and execute all of them in alphabetic order. Then
in vdsmd.init.in, it calls init_common.sh before actually starts vdsm
daemon.
After move these things out of vdsmd.init.in, it slims to about 100
lines of code, and most of them are boilerplate. Then in Debian, we
should write vdsmd_debian.init.in using Debian's boilerplate, which fits
to Debian's SysV environment. Debians SysV environment is a bit
different from Red Hat family's. Red Hat provides /etc/init.d/functions
and Debian provides /lib/lsb/init-functions, the error logging function
and daemon function are different.
The VDSM SystemD unit calls vdmsd.init.in to start daemon, after we move
initialization to init_common.sh and its slaves, we can call
init_common.sh in vdsmd.service then start "/usr/bin/python
/usr/share/vdsm/vdsm" directly. SystemD knows how to daemonize and
respawn a process, so we can make use its native ability.
As regard to Upstart on Ubuntu, we can write an Upstart job that calls
init_common.sh, then use Upstart's native ability to daemonize and
respawn vdsm service process -- just a few lines of declaration.
In this way we relieve the headache of supporting a monolithic
vdsmd.init.in in different systems. After I split initialization
operations into init_*_*.sh scripts, I find they can be modularized.
There are almost no dependency in these init_*_*.sh scripts. Supporting
them in different systems is not hard, and we can add/remove
initialization scripts when porting VDSM to a new system.
We may has concerns on libvirt configuration. The libvirt configuration
code is complicated in vdsmd.init.in. After the refactoring, it would be
more complicated to improve it. I think the code is modular enough, I
did not change the code when I moved it. I also have an idea on how to
simplify it. If you take a look at configure_libvirt function in
vdsmd.init.in, you will find the code is mixed with the data. The
mechanism of configuration is mixed with what we'd like to configure.
For example,
set_if_default $lconf listen_addr \"0.0.0.0\"
set_if_default $lconf unix_sock_group \"kvm\"
set_if_default $lconf unix_sock_rw_perms \"0770\"
...
set_if_default $lconf keepalive_interval -1
I think we can split the configuration settings into a template file,
for example,
listen_addr="0.0.0.0"
unix_sock_group="kvm"
unix_sock_rw_perms="0770"
...
keepalive_interval=-1
Then write a function that reads this template and "merge" the settings
into libvirtd.conf. Then for different systems we can ship VDSM with
different template with various settings, and the code implementing
configuring remains the same. The template can also support dynamic
values, for example,
host_uuid<="$(uuidgen)"
Means it should eval the value before write it to libvirtd configure file.
[1] Split vdsm init script into pieces http://gerrit.ovirt.org/#/c/14826/
--
Thanks and best regards!
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397
