Recent changes in vdsmd startup

[Itamar Heim]

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)