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