[vdsm] Recent changes in vdsmd startup

[Alon Bar-Lev]

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

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 at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>
> 
>