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 \"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: [phone]

Hey,

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.

Regards,
Yaniv Bronhaim.


----- Original Message -----
>  From: "Zhou Zheng Sheng"
> <zhshzhou(a)linux.vnet.ibm.com&gt;
>  To: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;
>  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 \"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: [phone]
>  
>  _______________________________________________
>  vdsm-devel mailing list
>  vdsm-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

Hi,

on 05/28/2013 17:26, Yaniv Bronheim wrote:
>  Hey,
>  
>  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/). 
Yes. After supervdsm starts as service, we can add dependency
declarations easily. It's not conflicting with refactoring vdsm init
script. I can help to review the supervdsm patch to make it done faster.

>  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. 
The Debian ships with /lib/lsb/init-functions, and Red Hat family (such
as CentOS, RHEL6) ship with /etc/init.d/functions. To print the error
message and daemonize the service process, we call different utility
functions in different system thought they are all SysV. The service
script boilerplate in Debian is different from Red Hat family as well.
So we want provide dedicated init script for respective systems. To
re-use start_needed_srv and load-needed-modules in different SysV init
scripts, I move them out.

>  gencerts, syslog_available, tune_system, test_space_and_lo,
> prepare_dirs - can be scripts that we run before start as you did.
>  
>  Regards,
>  Yaniv Bronhaim.
>   
I agree some of the initialize operations can be moved to vdsm-tool. I
think we can do this in future patch after we port VDSM init script to
Ubuntu. I'd prefer start small, not to do all the things in one batch.
Once we have VDSM run on Ubuntu, we can improve it step by step.
-- 
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: [phone]

Hey, 

If I understand it correctly start_needed_srv and load-needed-modules is needed only by
RedHat family dists, so you can keep it in vdsmd start function.
All the others (systemd, upstat and openrc) have dependencies mechanism that we can use
(as *.service Requires field)

Supervdsm service implementation almost complete, and hopefully will merged soon. It
doesn't need to bother us, as it just requires another dependency between it and vdsmd
as you mentioned..

If we've already started to work on the splitting part, we can call the scripts we
need by vdsm-tool right now. later we can translate the code to python .
I think it might be better and more seemlier to what we expect it to be when we'll
finish.
Each service control will use the needed vdsm-tool command to initialize vdsm deamon,
instead of running all the scripts

----- Original Message -----
>  From: "Zhou Zheng Sheng"
> <zhshzhou(a)linux.vnet.ibm.com&gt;
>  To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;
>  Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;
>  Sent: Wednesday, May 29, 2013 9:12:30 AM
>  Subject: Re: [vdsm] About vdsmd init script
>  
>  
>  Hi,
>  
>  on 05/28/2013 17:26, Yaniv Bronheim wrote:
>  > Hey,
>  > 
>  > 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/).
>  
>  Yes. After supervdsm starts as service, we can add dependency
>  declarations easily. It's not conflicting with refactoring vdsm init
>  script. I can help to review the supervdsm patch to make it done faster.
>  
>  > 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.
>  
>  The Debian ships with /lib/lsb/init-functions, and Red Hat family (such
>  as CentOS, RHEL6) ship with /etc/init.d/functions. To print the error
>  message and daemonize the service process, we call different utility
>  functions in different system thought they are all SysV. The service
>  script boilerplate in Debian is different from Red Hat family as well.
>  So we want provide dedicated init script for respective systems. To
>  re-use start_needed_srv and load-needed-modules in different SysV init
>  scripts, I move them out.
>  
>  > gencerts, syslog_available, tune_system, test_space_and_lo, prepare_dirs -
>  > can be scripts that we run before start as you did.
>  > 
>  > Regards,
>  > Yaniv Bronhaim.
>  > 
>  
>  I agree some of the initialize operations can be moved to vdsm-tool. I
>  think we can do this in future patch after we port VDSM init script to
>  Ubuntu. I'd prefer start small, not to do all the things in one batch.
>  Once we have VDSM run on Ubuntu, we can improve it step by step.
>  --
>  Thanks and best regards!
>  
>  Zhou Zheng Sheng / 周征晟
>  E-mail: zhshzhou(a)linux.vnet.ibm.com
>  Telephone: [phone]
>  
>

[Dan Kenigsberg]

On Wed, May 29, 2013 at 08:38:42AM -0400, Yaniv Bronheim wrote:
>  Hey, 
>  
>  If I understand it correctly start_needed_srv and load-needed-modules
>  is needed only by RedHat family dists, so you can keep it in vdsmd
>  start function.  All the others (systemd, upstat and openrc) have
>  dependencies mechanism that we can use (as *.service Requires field) 
I would not pile start_needed_srv and load-needed-modules together.
Declaring the needed modules in a /etc/modprobe.d/vdsm.conf file may not
be enough, since we would like vdsm and its networking functionality to
be functional before the host is rebooting. We may consider moving
load-needed-modules to ovirt-host-deploy, though.

>  
>  Supervdsm service implementation almost complete, and hopefully will merged soon. It
> doesn't need to bother us, as it just requires another dependency between it and vdsmd
> as you mentioned..
>  
>  If we've already started to work on the splitting part, we can call
>  the scripts we need by vdsm-tool right now. later we can translate the
>  code to python .  I think it might be better and more seemlier to what
>  we expect it to be when we'll finish. 
>  Each service control will use the needed vdsm-tool command to
>  initialize vdsm deamon, instead of running all the scripts 
I too have a concern about http://gerrit.ovirt.org/14826/ 's current
approach, of splitting functionality into before_vdsm_start hooks. The
concern is about the semantics of the hooks system: it is ment to be for
optional additions to the vdsm, and here it is being used for
crucially-required bits of vdsmd startup.

Another concern is that I do not trust bash. The patch improves things
by avoiding the unmaintainably-long script that we have. Still, I would
prefer to move the code to vdsm-tool and to Python. I do wonder if this
is a case of "best" blocking "better"...

I wonder if we can solicit more opinions about this.

>  
>  ----- Original Message -----
>  > From: "Zhou Zheng Sheng" <zhshzhou(a)linux.vnet.ibm.com&gt;
>  > To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;
>  > Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;
>  > Sent: Wednesday, May 29, 2013 9:12:30 AM
>  > Subject: Re: [vdsm] About vdsmd init script
>  > 
>  > 
>  > Hi,
>  > 
>  > on 05/28/2013 17:26, Yaniv Bronheim wrote:
>  > > Hey,
>  > > 
>  > > 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/).
>  > 
>  > Yes. After supervdsm starts as service, we can add dependency
>  > declarations easily. It's not conflicting with refactoring vdsm init
>  > script. I can help to review the supervdsm patch to make it done faster.
>  > 
>  > > 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.
>  > 
>  > The Debian ships with /lib/lsb/init-functions, and Red Hat family (such
>  > as CentOS, RHEL6) ship with /etc/init.d/functions. To print the error
>  > message and daemonize the service process, we call different utility
>  > functions in different system thought they are all SysV. The service
>  > script boilerplate in Debian is different from Red Hat family as well.
>  > So we want provide dedicated init script for respective systems. To
>  > re-use start_needed_srv and load-needed-modules in different SysV init
>  > scripts, I move them out.
>  > 
>  > > gencerts, syslog_available, tune_system, test_space_and_lo, prepare_dirs -
>  > > can be scripts that we run before start as you did.
>  > > 
>  > > Regards,
>  > > Yaniv Bronhaim.
>  > > 
>  > 
>  > I agree some of the initialize operations can be moved to vdsm-tool. I
>  > think we can do this in future patch after we port VDSM init script to
>  > Ubuntu. I'd prefer start small, not to do all the things in one batch.
>  > Once we have VDSM run on Ubuntu, we can improve it step by step.
>  > --
>  > Thanks and best regards!
>  > 
>  > Zhou Zheng Sheng / 周征晟
>  > E-mail: zhshzhou(a)linux.vnet.ibm.com
>  > Telephone: [phone]

[Alon Bar-Lev]

----- Original Message -----
>  From: "Dan Kenigsberg" <danken(a)redhat.com&gt;
>  To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;
>  Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;
>  Sent: Sunday, June 2, 2013 5:50:52 PM
>  Subject: Re: [vdsm] About vdsmd init script
>  
>  On Wed, May 29, 2013 at 08:38:42AM -0400, Yaniv Bronheim wrote:
>  > Hey,
>  > 
>  > If I understand it correctly start_needed_srv and load-needed-modules
>  > is needed only by RedHat family dists, so you can keep it in vdsmd
>  > start function.  All the others (systemd, upstat and openrc) have
>  > dependencies mechanism that we can use (as *.service Requires field)
>  
>  I would not pile start_needed_srv and load-needed-modules together.
>  Declaring the needed modules in a /etc/modprobe.d/vdsm.conf file may not
>  be enough, since we would like vdsm and its networking functionality to
>  be functional before the host is rebooting. We may consider moving
>  load-needed-modules to ovirt-host-deploy, though. 
I do not understand, can you please explain so more... what exactly is the problem?
ovirt-host-deploy should not be mandatory tool, it is automation.
If we need to load modules, can't we do this using dependencies or other mechanism, so
that it will be transparent to user?

>  
>  > 
>  > Supervdsm service implementation almost complete, and hopefully will merged
>  > soon. It doesn't need to bother us, as it just requires another dependency
>  > between it and vdsmd as you mentioned..
>  > 
>  > If we've already started to work on the splitting part, we can call
>  > the scripts we need by vdsm-tool right now. later we can translate the
>  > code to python .  I think it might be better and more seemlier to what
>  > we expect it to be when we'll finish.
>  
>  > Each service control will use the needed vdsm-tool command to
>  > initialize vdsm deamon, instead of running all the scripts
>  
>  I too have a concern about http://gerrit.ovirt.org/14826/ 's current
>  approach, of splitting functionality into before_vdsm_start hooks. The
>  concern is about the semantics of the hooks system: it is ment to be for
>  optional additions to the vdsm, and here it is being used for
>  crucially-required bits of vdsmd startup.
>  
>  Another concern is that I do not trust bash. 
POSIX shell (I hope) and not bash.
There is nothing wrong with using shell scripts, it is a matter of taste...

>  The patch improves things
>  by avoiding the unmaintainably-long script that we have. Still, I would
>  prefer to move the code to vdsm-tool and to Python. I do wonder if this
>  is a case of "best" blocking "better"...
>  
>  I wonder if we can solicit more opinions about this. 
This is transparent to the idea of having downstream specific wrapper and common logic, I
am fine with either.
 
>  > 
>  > ----- Original Message -----
>  > > From: "Zhou Zheng Sheng" <zhshzhou(a)linux.vnet.ibm.com&gt;
>  > > To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;
>  > > Cc: "VDSM Project Development"
> <vdsm-devel(a)lists.fedorahosted.org&gt;
>  > > Sent: Wednesday, May 29, 2013 9:12:30 AM
>  > > Subject: Re: [vdsm] About vdsmd init script
>  > > 
>  > > 
>  > > Hi,
>  > > 
>  > > on 05/28/2013 17:26, Yaniv Bronheim wrote:
>  > > > Hey,
>  > > > 
>  > > > 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/).
>  > > 
>  > > Yes. After supervdsm starts as service, we can add dependency
>  > > declarations easily. It's not conflicting with refactoring vdsm init
>  > > script. I can help to review the supervdsm patch to make it done faster.
>  > > 
>  > > > 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.
>  > > 
>  > > The Debian ships with /lib/lsb/init-functions, and Red Hat family (such
>  > > as CentOS, RHEL6) ship with /etc/init.d/functions. To print the error
>  > > message and daemonize the service process, we call different utility
>  > > functions in different system thought they are all SysV. The service
>  > > script boilerplate in Debian is different from Red Hat family as well.
>  > > So we want provide dedicated init script for respective systems. To
>  > > re-use start_needed_srv and load-needed-modules in different SysV init
>  > > scripts, I move them out.
>  > > 
>  > > > gencerts, syslog_available, tune_system, test_space_and_lo,
>  > > > prepare_dirs -
>  > > > can be scripts that we run before start as you did.
>  > > > 
>  > > > Regards,
>  > > > Yaniv Bronhaim.
>  > > > 
>  > > 
>  > > I agree some of the initialize operations can be moved to vdsm-tool. I
>  > > think we can do this in future patch after we port VDSM init script to
>  > > Ubuntu. I'd prefer start small, not to do all the things in one batch.
>  > > Once we have VDSM run on Ubuntu, we can improve it step by step.
>  > > --
>  > > Thanks and best regards!
>  > > 
>  > > Zhou Zheng Sheng / 周征晟
>  > > E-mail: zhshzhou(a)linux.vnet.ibm.com
>  > > Telephone: [phone]
>  _______________________________________________
>  vdsm-devel mailing list
>  vdsm-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

[Dan Kenigsberg]

On Sun, Jun 02, 2013 at 11:23:31AM -0400, Alon Bar-Lev wrote:
>  
>  
>  ----- Original Message -----
>  > From: "Dan Kenigsberg" <danken(a)redhat.com&gt;
>  > To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;
>  > Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org&gt;
>  > Sent: Sunday, June 2, 2013 5:50:52 PM
>  > Subject: Re: [vdsm] About vdsmd init script
>  > 
>  > On Wed, May 29, 2013 at 08:38:42AM -0400, Yaniv Bronheim wrote:
>  > > Hey,
>  > > 
>  > > If I understand it correctly start_needed_srv and load-needed-modules
>  > > is needed only by RedHat family dists, so you can keep it in vdsmd
>  > > start function.  All the others (systemd, upstat and openrc) have
>  > > dependencies mechanism that we can use (as *.service Requires field)
>  > 
>  > I would not pile start_needed_srv and load-needed-modules together.
>  > Declaring the needed modules in a /etc/modprobe.d/vdsm.conf file may not
>  > be enough, since we would like vdsm and its networking functionality to
>  > be functional before the host is rebooting. We may consider moving
>  > load-needed-modules to ovirt-host-deploy, though.
>  
>  I do not understand, can you please explain so more... what exactly is the problem?
>  ovirt-host-deploy should not be mandatory tool, it is automation.
>  If we need to load modules, can't we do this using dependencies or
>  other mechanism, so that it will be transparent to user? 
Maybe we can - I do not know how. We need to have tun, bonding and 8021q
inside the kernel when vdsm starts. That's easy to do after boot
(/etc/modprobe.d/vdsm.conf) but how can we do it just after vdsm is
installed? We cannot use rpm's %post script, as it must never change the
kernel state (think ovirt-node building).

(not very important. This is an execursion to the main question of this
thead.)