On 10/10/2013 07:43 PM, Alon Bar-Lev wrote:



----- Original Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Alon Bar-Lev" <alo...@redhat.com>
Cc: "Yaniv Bronheim" <ybron...@redhat.com>, "arch" <a...@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" <ih...@redhat.com>
To: "Yaniv Bronheim" <ybron...@redhat.com>
Cc: "arch" <a...@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" <ih...@redhat.com>
To: "Yaniv Bronheim" <ybron...@redhat.com>
Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>,
"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
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?


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




_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to