----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Yaniv Bronheim" <[email protected]>, "arch" <[email protected]>, "VDSM > Project Development" > <[email protected]> > Sent: Thursday, October 10, 2013 7:39:35 PM > Subject: Re: [vdsm] Recent changes in vdsmd startup > > On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" <[email protected]> > >> To: "Yaniv Bronheim" <[email protected]> > >> Cc: "arch" <[email protected]>, "VDSM Project Development" > >> <[email protected]> > >> Sent: Thursday, October 10, 2013 7:37:14 PM > >> Subject: Re: [vdsm] Recent changes in vdsmd startup > >> > >> On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Itamar Heim" <[email protected]> > >>>> To: "Yaniv Bronheim" <[email protected]> > >>>> Cc: "VDSM Project Development" <[email protected]>, > >>>> "arch" > >>>> <[email protected]> > >>>> Sent: Thursday, October 10, 2013 5:24:40 PM > >>>> Subject: Re: Recent changes in vdsmd startup > >>>> > >>>> On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: > >>>>> Hey Everybody, > >>>>> FYI, Recently we merged a fix that changes the way vdsmd starts. Before > >>>>> that "service vdsmd start" command performed its main logic in addition > >>>>> to > >>>>> related services manipulation, as configure libvirt service and restart > >>>>> it > >>>>> for example. > >>>>> Now we are trying to avoid that and only alert the user if restart or > >>>>> other > >>>>> operations on related services are required. > >>>>> > >>>>> So now when you perform vdsmd start after clear installation you will > >>>>> see: > >>>>> ~$ sudo service vdsmd restart > >>>>> Shutting down vdsm daemon: > >>>>> vdsm watchdog stop [ OK ] > >>>>> vdsm: not running [FAILED] > >>>>> vdsm: Running run_final_hooks > >>>>> vdsm stop [ OK ] > >>>>> supervdsm start [ OK ] > >>>>> vdsm: Running run_init_hooks > >>>>> vdsm: Running gencerts > >>>>> hostname: Unknown host > >>>>> vdsm: Running check_libvirt_configure > >>>>> libvirt is not configured for vdsm yet > >>>>> Perform 'vdsm-tool libvirt-configure' before starting vdsmd > >>>>> vdsm: failed to execute check_libvirt_configure, error code 1 > >>>>> vdsm start [FAILED] > >>>>> > >>>>> This asks you to run "vdsm-tool libvirt-configure" > >>>>> After running it you should see: > >>>>> > >>>>> ~$ sudo vdsm-tool libvirt-configure > >>>>> Stopping libvirtd daemon: [ OK ] > >>>>> libvirt is not configured for vdsm yet > >>>>> Reconfiguration of libvirt is done. > >>>>> > >>>>> To start working with the new configuration, execute: > >>>>> 'vdsm-tool libvirt-configure-services-restart' > >>>>> This will manage restarting of the following services: > >>>>> libvirtd, supervdsmd > >>>>> > >>>>> After performing: 'vdsm-tool libvirt-configure-services-restart' you > >>>>> are > >>>>> ready to start vdsmd again as usual. > >>>>> > >>>>> All those vdsm-tool commands require root privileges, otherwise it'll > >>>>> alert > >>>>> and stop the operation. > >>>>> Over systemd the errors\output can be watched in /var/log/messages > >>>>> > >>>>> Thanks, > >>>>> Yaniv Bronhaim. > >>>>> _______________________________________________ > >>>>> Arch mailing list > >>>>> [email protected] > >>>>> http://lists.ovirt.org/mailman/listinfo/arch > >>>>> > >>>> > >>>> how will this affect the following use cases: > >>>> > >>>> 1. i added a new host to the system via the engine. > >>>> at the end of the installation i expect the host to work without admin > >>>> having to do any operation on the host. > >>>> > >>>> 2. i update a host to latest vdsm version via the engine. > >>>> at the end of the update i expect the host to be updated without admin > >>>> having to do any operation on the host > >>>> > >>> > >>> Of course it shouldn't effect any of the deploy process. If using the > >>> host-deploy, the host-deploy process should take care of stopping, > >>> starting and other managing that can be required before starting vdsmd, > >>> and it is taking care of. > >>> The prints I copied above are relevant only if user tries to install and > >>> start vdsmd manually > >> > >> great. so how does backward compatibility work? i have a 3.2 engine, and > >> i deploy latest vdsm due to some bug fixes. > >> (i.e., i didn't get new host-deploy) > > > > This was already supported in last iteration. > > > > The init.d and systemd script support reconfigure verb that is executed > > ever since vdsm-bootstrap, these are kept for backward compatibility. > > so what happens to 3.2 engine with this new vdsm, without this patch? > http://gerrit.ovirt.org/20102
this patch is just adjustment to whatever yaniv plans now. up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above. now host-deploy will be adjusted to call a single verb to configure whatever need to be configured by vdsm. waiting for interface of vdsm-tool to stabilize before attempting to fix. 3.2, 3.1, 3.0 uses the old method of reconfigure, it does not use vdsm tool. > > > > >> > >> _______________________________________________ > >> vdsm-devel mailing list > >> [email protected] > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >> > > _______________________________________________ vdsm-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
