[vdsm] Recent changes in vdsmd startup

[Itamar Heim]

On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:
>
>
> ----- 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.

so what happens if the vdsm on the host is an older 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
>>>>
>>
>>