[vdsm] vdsm rpm sanity test is failing
Hi, I sent a patch to vdsm in gerrit, but rpm sanity test is failing. Please suggest how to fix this. patch: http://gerrit.ovirt.org/#/c/17822/6 sanity test: http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/148/ -- regards Aravinda ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm rpm sanity test is failing
On Thu, Oct 10, 2013 at 08:48:00AM -0400, Eyal Edri wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Aravinda avish...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, ee...@redhat.com, ybron...@redhat.com Sent: Thursday, October 10, 2013 3:43:29 PM Subject: Re: [vdsm] vdsm rpm sanity test is failing On Thu, Oct 10, 2013 at 11:39:51AM +0530, Aravinda wrote: Hi, I sent a patch to vdsm in gerrit, but rpm sanity test is failing. Please suggest how to fix this. patch: http://gerrit.ovirt.org/#/c/17822/6 sanity test: http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/148/ Can we install glusterfs-3.4.1-2.el6 from https://koji.fedoraproject.org/koji/buildinfo?buildID=468826 on our el6 slave? i rather have a stable repo to use constantly and not specific pkg in koji. I think that we should take the glusterfs straight from Fedora EPEL6, as I would like to avoid shipping our own glusterfs in the ovirt repo. My request for a manaual fix is only to unbreak current situation. It is important to do that in order to ubreak the new rpm sanity test, which is going to save us this trouble in the future. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsm-4.12.1-4
Changes: = - remoteFileHandler: Add create exclusive option for truncateFile (BZ#979193) - oop: improve safety for truncateFile F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046682 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046573 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046734 -- Cheers Douglas ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Recent changes in vdsmd startup
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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
Il 10/10/2013 15:32, Yaniv Bronheim ha scritto: 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 Hi, is this change targeted to oVirt 3.3.z? or is it targeted to 3.4.0? I think it will affect hosted-engine-setup and host-deploy for all-in-one setups at least. Thanks, Yaniv Bronhaim. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org, Doron Fediuck dfedi...@redhat.com, Itamar Heim ih...@redhat.com, Yedidyah Bar David d...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Thursday, October 10, 2013 4:38:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup Il 10/10/2013 15:32, Yaniv Bronheim ha scritto: 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 Hi, is this change targeted to oVirt 3.3.z? or is it targeted to 3.4.0? I think it will affect hosted-engine-setup and host-deploy for all-in-one setups at least. I hope we took care about all points related to backwards compatibility and current host deploy process. Currently its targeted to 3.4.0 Thanks, Yaniv Bronhaim. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] 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 Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- 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 Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm rpm sanity test is failing
i added glusterfs-epel manually to centos slaves for now. it stills fails on vdsm hook and selinux: http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/label=centos64/163/console - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Eyal Edri ee...@redhat.com Cc: Aravinda avish...@redhat.com, vdsm-devel@lists.fedorahosted.org, ybron...@redhat.com Sent: Thursday, October 10, 2013 3:58:14 PM Subject: Re: [vdsm] vdsm rpm sanity test is failing On Thu, Oct 10, 2013 at 08:48:00AM -0400, Eyal Edri wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Aravinda avish...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, ee...@redhat.com, ybron...@redhat.com Sent: Thursday, October 10, 2013 3:43:29 PM Subject: Re: [vdsm] vdsm rpm sanity test is failing On Thu, Oct 10, 2013 at 11:39:51AM +0530, Aravinda wrote: Hi, I sent a patch to vdsm in gerrit, but rpm sanity test is failing. Please suggest how to fix this. patch: http://gerrit.ovirt.org/#/c/17822/6 sanity test: http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/148/ Can we install glusterfs-3.4.1-2.el6 from https://koji.fedoraproject.org/koji/buildinfo?buildID=468826 on our el6 slave? i rather have a stable repo to use constantly and not specific pkg in koji. I think that we should take the glusterfs straight from Fedora EPEL6, as I would like to avoid shipping our own glusterfs in the ovirt repo. My request for a manaual fix is only to unbreak current situation. It is important to do that in order to ubreak the new rpm sanity test, which is going to save us this trouble in the future. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- 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. ___ 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
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 ___ 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
Re: [vdsm] Recent changes in vdsmd startup
- 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. 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
Re: [vdsm] Recent changes in vdsmd startup
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
Re: [vdsm] Recent changes in vdsmd startup
- 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: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 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
Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:47 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: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 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? I don't follow... up until now host-deploy tried to
Re: [vdsm] Recent changes in vdsmd startup
- 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 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 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: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 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
Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 01:51:00PM -0400, 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 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 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: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 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 I think we've quite neglected a third case, of unattended `yum upgrade -y`. If and when we need to update BY_VDSM_VERS, this would result in a failure to restart vdsm. How should we handle that? I do not see a way other than adding libvirt-configure and libvirt condrestart to vdsm %postin. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org
Re: [vdsm] vdsm-4.12.1-4
On Thu, Oct 10, 2013 at 10:13:33AM -0400, Mike Burns wrote: On 10/10/2013 10:12 AM, Mike Burns wrote: On 10/10/2013 10:20 AM, Douglas Schilling Landgraf wrote: Changes: = - remoteFileHandler: Add create exclusive option for truncateFile (BZ#979193) - oop: improve safety for truncateFile F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046682 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046573 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046734 Done Done as in they're uploaded to updates-testing on ovirt.org Thanks! As Federico reported earlier, they are quite important. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen). - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 10:34:10 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On Thu, Oct 10, 2013 at 01:51:00PM -0400, 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 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 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: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 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
Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote: Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen). IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`. I'm trying to understand our action on the unattended upgrade path. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
