----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Alon Bar-Lev" <alo...@redhat.com> > Cc: "Yaniv Bronheim" <ybron...@redhat.com>, "arch" <arch@ovirt.org>, "VDSM > Project Development" > <vdsm-de...@lists.fedorahosted.org> > 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" <ih...@redhat.com> > >> To: "Alon Bar-Lev" <alo...@redhat.com> > >> Cc: "Yaniv Bronheim" <ybron...@redhat.com>, "arch" <arch@ovirt.org>, "VDSM > >> Project Development" > >> <vdsm-de...@lists.fedorahosted.org> > >> 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" <ih...@redhat.com> > >>>> To: "Yaniv Bronheim" <ybron...@redhat.com> > >>>> Cc: "arch" <arch@ovirt.org>, "VDSM Project Development" > >>>> <vdsm-de...@lists.fedorahosted.org> > >>>> 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" <ih...@redhat.com> > >>>>>> To: "Yaniv Bronheim" <ybron...@redhat.com> > >>>>>> Cc: "VDSM Project Development" <vdsm-de...@lists.fedorahosted.org>, > >>>>>> "arch" > >>>>>> <arch@ovirt.org> > >>>>>> 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 > >>>>>>> Arch@ovirt.org > >>>>>>> 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. """ > > > > > 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 > >>>> vdsm-de...@lists.fedorahosted.org > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>> > >> > >> > > _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
