----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Yaniv Bronheim" <ybron...@redhat.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > 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" <zhshz...@linux.vnet.ibm.com> > > > To: "Yaniv Bronheim" <ybron...@redhat.com> > > > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > > > 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: 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 vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
