----- Original Message -----
From: "Itamar Heim" iheim@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "Yaniv Bronheim" ybronhei@redhat.com, "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org 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" iheim@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "Yaniv Bronheim" ybronhei@redhat.com, "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@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" iheim@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "Yaniv Bronheim" ybronhei@redhat.com, "arch" arch@ovirt.org, "VDSM Project Development" vdsm-devel@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" iheim@redhat.com > To: "Yaniv Bronheim" ybronhei@redhat.com > Cc: "arch" arch@ovirt.org, "VDSM Project Development" > vdsm-devel@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" iheim@redhat.com >>> To: "Yaniv Bronheim" ybronhei@redhat.com >>> Cc: "VDSM Project Development" vdsm-devel@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.
"""
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 > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >