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
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" > To: "Alon Bar-Lev" > Cc: "arch" , "VDSM Project Development" > > 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" > > > To: "Alon Bar-Lev" > > > Cc: "Yaniv Bronheim" , "arch" , > > > "VDSM Project Development" > > > > > > 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" > > > >> To: "Alon Bar-Lev" > > > >> Cc: "Yaniv Bronheim" , "arch" , > > > >> "VDSM > > > >> Project Development" > > > >> > > > >> 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" > > > To: "Alon Bar-Lev" > > > Cc: "Yaniv Bronheim" , "arch" , > > > "VDSM > > > Project Development" > > > > > > 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" > > > >> To: "Yaniv Bronheim" > > > >> Cc: "arch" , "VDSM Project Development" > > > >> > > > >> 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" > > > To: "Yaniv Bronheim" > > > Cc: "VDSM Project Development" > > > , > > > "arch" > > > > > > 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
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
On Thu, Oct 10, 2013 at 01:51:00PM -0400, Alon Bar-Lev wrote: > > > - Original Message - > > From: "Itamar Heim" > > To: "Alon Bar-Lev" > > Cc: "Yaniv Bronheim" , "arch" , "VDSM > > Project Development" > > > > 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" > > >> To: "Alon Bar-Lev" > > >> Cc: "Yaniv Bronheim" , "arch" , > > >> "VDSM > > >> Project Development" > > >> > > >> 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" > > To: "Alon Bar-Lev" > > Cc: "Yaniv Bronheim" , "arch" , > > "VDSM > > Project Development" > > > > 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" > > >> To: "Yaniv Bronheim" > > >> Cc: "arch" , "VDSM Project Development" > > >> > > >> 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" > > To: "Yaniv Bronheim" > > Cc: "VDSM Project Development" , > > "arch" > > > > 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
Re: [vdsm] vdsm rpm sanity test is failing
On Thu, Oct 10, 2013 at 11:25:50AM -0400, Eyal Edri wrote: > 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 Thanks, Eyal! The selinux issue is to be solved only when Bug 1015068 - Current selinux policy prevents running a VM with volumes under /var/run/vdsm/storage is published to EL6.4.z. I hope this happens soon. Regarding the vhostmd dependency: would you agree to build it from source http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/vhostmd-0.4-2.7.el6.src.rpm ? If not, please exclude vdsm-hook-vdsmd from the sanity test. 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
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Yaniv Bronheim" , "arch" , "VDSM > Project Development" > > 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" > >> To: "Alon Bar-Lev" > >> Cc: "Yaniv Bronheim" , "arch" , "VDSM > >> Project Development" > >> > >> 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" > To: "Alon Bar-Lev" > Cc: "Yaniv Bronheim" , "arch" , > "VDSM > Project Development" > > 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" > >> To: "Yaniv Bronheim" > >> Cc: "arch" , "VDSM Project Development" > >> > >> 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" > To: "Yaniv Bronheim" > Cc: "VDSM Project Development" , > "arch" > > 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 > > >>> > >
Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:47 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "Alon Bar-Lev" Cc: "Yaniv Bronheim" , "arch" , "VDSM Project Development" 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" To: "Alon Bar-Lev" Cc: "Yaniv Bronheim" , "arch" , "VDSM Project Development" 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" To: "Yaniv Bronheim" Cc: "arch" , "VDSM Project Development" 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" To: "Yaniv Bronheim" Cc: "VDSM Project Development" , "arch" 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 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? 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.
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Yaniv Bronheim" , "arch" , "VDSM > Project Development" > > 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" > >> To: "Alon Bar-Lev" > >> Cc: "Yaniv Bronheim" , "arch" , "VDSM > >> Project Development" > >> > >> 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" > To: "Yaniv Bronheim" > Cc: "arch" , "VDSM Project Development" > > 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" > >> To: "Yaniv Bronheim" > >> Cc: "VDSM Project Development" , > >> "arch" > >> > >> 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
Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:43 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "Alon Bar-Lev" Cc: "Yaniv Bronheim" , "arch" , "VDSM Project Development" 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" To: "Yaniv Bronheim" Cc: "arch" , "VDSM Project Development" 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" To: "Yaniv Bronheim" Cc: "VDSM Project Development" , "arch" 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
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Yaniv Bronheim" , "arch" , "VDSM > Project Development" > > 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" > >> To: "Yaniv Bronheim" > >> Cc: "arch" , "VDSM Project Development" > >> > >> 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" > To: "Yaniv Bronheim" > Cc: "VDSM Project Development" , > "arch" > > 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 i
Re: [vdsm] Recent changes in vdsmd startup
On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: - Original Message - From: "Itamar Heim" To: "Yaniv Bronheim" Cc: "arch" , "VDSM Project Development" 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" To: "Yaniv Bronheim" Cc: "VDSM Project Development" , "arch" 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" > To: "Yaniv Bronheim" > Cc: "arch" , "VDSM Project Development" > > 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" > >> To: "Yaniv Bronheim" > >> Cc: "VDSM Project Development" , "arch" > >> > >> 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 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: "Itamar Heim" To: "Yaniv Bronheim" Cc: "VDSM Project Development" , "arch" 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] 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" > To: "Eyal Edri" > Cc: "Aravinda" , 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" > > > To: "Aravinda" > > > 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
- Original Message - > From: "Itamar Heim" > To: "Yaniv Bronheim" > Cc: "VDSM Project Development" , "arch" > > 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] 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] vdsm-4.12.1-4
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm-4.12.1-4
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 ___ 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" > To: "Yaniv Bronheim" > Cc: "VDSM Project Development" , "arch" > , "Doron Fediuck" > , "Itamar Heim" , "Yedidyah Bar David" > , "Alon Bar-Lev" > > 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
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
[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
[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
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" > > To: "Aravinda" > > 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] vdsm rpm sanity test is failing
- Original Message - > From: "Dan Kenigsberg" > To: "Aravinda" > 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. > > Dan. > ___ 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 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? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
