----- 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 8:33:39 PM > Subject: Re: [vdsm] Recent changes in vdsmd startup > > On 10/10/2013 07:47 PM, Alon Bar-Lev wrote: > > > > > > ----- 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:45:36 PM > >> Subject: Re: [vdsm] Recent changes in vdsmd startup > >> > >> On 10/10/2013 07:43 PM, Alon Bar-Lev wrote: > >>> > >>> > >>> ----- 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. > >> > >> so what happens if the vdsm on the host is an older vdsm? > > > > I don't follow... > > """ > >>> up until now host-deploy tried to execute vdsm-tool libvirt-configure and > >>> if fails it tries the old way as I described above. > > """ > > yes. but the new host-deploy will not do the fallback iiuc? >
fallback is relevant only for the component which knows legacy and new methods which is the new host-deploy (1.1). > > > >> > >>> > >>> 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 > >>>>>> > >>>> > >>>> > >> > >> > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
