I think that libvirt_configure part can be an external module (maybe python 
module) that can be initiated by vdsm-tool,
It should work with template or conf.default as you mentioned, and we should 
call it before starting the service, I think it should be a module as it also 
should include all the part of libvirtd_sysv2upstart, libvirtd_reconfigure, 
libvirtd_configure, test_conflicting_conf scripts.

Also, keep in mind that we plan to split vdsm to 2 services - one for vdsmd and 
one for supervdsmd, both should be initiated at startup and should be depended 
on eachother (http://gerrit.ovirt.org/#/c/11051/).

The other parts that you want to take out of vdsmd script are:
shutdown-conflict-srv - could be also as part of the tool
nwfliter, dummybr - both python scripts that we run, why not part of the tool 
as well?
start_needed_srv, load-needed-modules - only sysv and debian need it if I 
understand correctly. systemd,upstat,openrc can use their init script 
parameters. so why take them out? in each start function we'll start and load 
the needed services and modules. systemd,upstat,openrc don't need custom start 
function anyway.
gencerts, syslog_available, tune_system, test_space_and_lo, prepare_dirs - can 
be scripts that we run before start as you did.

Yaniv Bronhaim.

----- Original Message -----
> From: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
> Sent: Tuesday, May 28, 2013 8:03:06 AM
> Subject: [vdsm] About vdsmd init script
> 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 \"\"
> 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=""
> 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
vdsm-devel mailing list

Reply via email to