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: zhshz...@linux.vnet.ibm.com Telephone: 86-10-82454397 _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
