From asegurap at redhat.com Tue Oct 1 10:28:38 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Tue, 1 Oct 2013 06:28:38 -0400 (EDT) Subject: vdsm-functional-tests (networking) In-Reply-To: <408809225.546686.1380621248345.JavaMail.root@redhat.com> References: <408809225.546686.1380621248345.JavaMail.root@redhat.com> Message-ID: <1562313804.574856.1380623318181.JavaMail.root@redhat.com> Hi, For each new patchset you submit, if it touches any of the networking files (vdsm/vm.py is not included as it is not really covered by the net func tests), the whole functional tests will be triggered and run by jenkins. Best regards, Toni From ovedo at redhat.com Thu Oct 3 12:29:15 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 3 Oct 2013 08:29:15 -0400 (EDT) Subject: hosted Engine - moving a host to maintenance In-Reply-To: <1478382329.1187100.1380800832485.JavaMail.root@redhat.com> Message-ID: <2081015268.1209230.1380803355828.JavaMail.root@redhat.com> Hey, When moving a host to maintenance, the oVirt engine migrates all the running VMs to another host. If this host is the one running the hosted engine, then the hosted engine VM needs to be migrated as well. However, the hosted engine HA cluster might not be identical to the oVirt cluster (the oVirt cluster will usually be a superset of the HA one). So, in order to move a host to maintenance in a hosted engine environment we thought of doing the following: 1. VDSM changes - Report the HA agent score (if HA agent exists on host) 2. HA agent changes - provide an API to get the score, for VDSM to use 3. Engine changes - Add a scheduling filter, to filter out all hosts without a score, when the VM in question is the hosted engine - Add a weight filter, weighting hosts the "max weight" - the HA weight (further normalization might be needed here, I guess) - Marking the hosted engine VM as manual-migration 4. Add the score to the engine (in VdsDynamic). Issues with this approach: 1. Moving a host to maintenance will stay in "preparing for maintenance", until you manually migrate the hosted engine VM - Possible solution: define the VM as migratable, and add a condition to the load balancing logic to prevent it from migrating it 2. If the migration takes too much time that might cause it to abort, and do decrease the hosted engine performance. - Two alternatives here to prevent migration, or to address a scenario of aborted migration: a. To solve it perhaps we can add a "re-elect" command to the HA agents, to initiate a re-election of the host running the hosted engine VM: * add a re-election initiated bit to each host * if some host initiated a re-election, stop the VM and run it on another host according to the score * when the re-election is finished clear *ALL* re-election bits b. When asked using CLI or when the hosted-engine VM goes down (stopped by vdsm), the HA logic will temporary reduce its score to allow others to be elected. 3. Changing the cluster policy to a policy without the new filter / weight policy units will cancel this entire behaviour - Perhaps we can put some units in by default in the UI, allowing users to remove them. Thoughts and comments are welcome. Thank you, Oved From danken at redhat.com Wed Oct 9 11:55:03 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 9 Oct 2013 12:55:03 +0100 Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer Message-ID: <20131009115503.GF15427@redhat.com> Recently, the Vdsm branch ovirt-3.3 was rebased on a relatively-stabilized vdsm-4.13.0. As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large micro version. Plenty of bug fixes are expected to be suggested to this branch. Currently, Federico is responsible to merge patches for oVirt-3.3.1, with my assistance. I would like to nominate Yaniv to join us in this delicate task: on one hand we should fix as many problems, but on the other hand - avoid regressions and needless surprises. It is a micro version after all. Yaniv has a wide understanding of Vdsm internals, and I am certain he would know how to solve problems introduced by patches approved by him. Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. Dan. From dougsland at redhat.com Wed Oct 9 14:13:36 2013 From: dougsland at redhat.com (Douglas Schilling Landgraf) Date: Wed, 09 Oct 2013 10:13:36 -0400 Subject: [vdsm] suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer In-Reply-To: <20131009115503.GF15427@redhat.com> References: <20131009115503.GF15427@redhat.com> Message-ID: <52556490.4090908@redhat.com> On 10/09/2013 07:55 AM, Dan Kenigsberg wrote: > Recently, the Vdsm branch ovirt-3.3 was rebased on a > relatively-stabilized vdsm-4.13.0. > > As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large > micro version. Plenty of bug fixes are expected to be suggested to this > branch. > > Currently, Federico is responsible to merge patches for oVirt-3.3.1, > with my assistance. I would like to nominate Yaniv to join us in this > delicate task: on one hand we should fix as many problems, but on the > other hand - avoid regressions and needless surprises. It is a micro > version after all. > > Yaniv has a wide understanding of Vdsm internals, and I am certain he > would know how to solve problems introduced by patches approved by him. > > Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. +1 -- Cheers Douglas From fsimonce at redhat.com Wed Oct 9 15:24:54 2013 From: fsimonce at redhat.com (Federico Simoncelli) Date: Wed, 9 Oct 2013 11:24:54 -0400 (EDT) Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer In-Reply-To: <20131009115503.GF15427@redhat.com> References: <20131009115503.GF15427@redhat.com> Message-ID: <1910761292.5281274.1381332294364.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Wednesday, October 9, 2013 1:55:03 PM > Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer > > Recently, the Vdsm branch ovirt-3.3 was rebased on a > relatively-stabilized vdsm-4.13.0. > > As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large > micro version. Plenty of bug fixes are expected to be suggested to this > branch. > > Currently, Federico is responsible to merge patches for oVirt-3.3.1, > with my assistance. I would like to nominate Yaniv to join us in this > delicate task: on one hand we should fix as many problems, but on the > other hand - avoid regressions and needless surprises. It is a micro > version after all. > > Yaniv has a wide understanding of Vdsm internals, and I am certain he > would know how to solve problems introduced by patches approved by him. > > Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. +1 -- Federico From ybronhei at redhat.com Thu Oct 10 13:32:47 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Thu, 10 Oct 2013 09:32:47 -0400 (EDT) Subject: Recent changes in vdsmd startup In-Reply-To: <264332630.2481069.1381409449106.JavaMail.root@redhat.com> Message-ID: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> 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. From sbonazzo at redhat.com Thu Oct 10 13:38:36 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Thu, 10 Oct 2013 15:38:36 +0200 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> Message-ID: <5256ADDC.2060001@redhat.com> 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 at 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 From ybronhei at redhat.com Thu Oct 10 13:43:05 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Thu, 10 Oct 2013 09:43:05 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <5256ADDC.2060001@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256ADDC.2060001@redhat.com> Message-ID: <1365373926.2507854.1381412585337.JavaMail.root@redhat.com> ----- 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 at 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 > From iheim at redhat.com Thu Oct 10 14:24:40 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 10 Oct 2013 17:24:40 +0300 Subject: Recent changes in vdsmd startup In-Reply-To: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> Message-ID: <5256B8A8.5070007@redhat.com> On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: > Hey Everybody, > FYI, Recently we merged a fix that changes the way vdsmd starts. Before that "service vdsmd start" command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. > Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. > > So now when you perform vdsmd start after clear installation you will see: > ~$ sudo service vdsmd restart > Shutting down vdsm daemon: > vdsm watchdog stop [ OK ] > vdsm: not running [FAILED] > vdsm: Running run_final_hooks > vdsm stop [ OK ] > supervdsm start [ OK ] > vdsm: Running run_init_hooks > vdsm: Running gencerts > hostname: Unknown host > vdsm: Running check_libvirt_configure > libvirt is not configured for vdsm yet > Perform 'vdsm-tool libvirt-configure' before starting vdsmd > vdsm: failed to execute check_libvirt_configure, error code 1 > vdsm start [FAILED] > > This asks you to run "vdsm-tool libvirt-configure" > After running it you should see: > > ~$ sudo vdsm-tool libvirt-configure > Stopping libvirtd daemon: [ OK ] > libvirt is not configured for vdsm yet > Reconfiguration of libvirt is done. > > To start working with the new configuration, execute: > 'vdsm-tool libvirt-configure-services-restart' > This will manage restarting of the following services: > libvirtd, supervdsmd > > After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. > > All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. > Over systemd the errors\output can be watched in /var/log/messages > > Thanks, > Yaniv Bronhaim. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host Thanks, Itamar From ybronhei at redhat.com Thu Oct 10 14:38:14 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Thu, 10 Oct 2013 10:38:14 -0400 (EDT) Subject: Recent changes in vdsmd startup In-Reply-To: <5256B8A8.5070007@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> Message-ID: <986640714.2530258.1381415894947.JavaMail.root@redhat.com> ----- 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 > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > > how will this affect the following use cases: > > 1. i added a new host to the system via the engine. > at the end of the installation i expect the host to work without admin > having to do any operation on the host. > > 2. i update a host to latest vdsm version via the engine. > at the end of the update i expect the host to be updated without admin > having to do any operation on the host > Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. The prints I copied above are relevant only if user tries to install and start vdsmd manually > Thanks, > Itamar > From iheim at redhat.com Thu Oct 10 16:37:14 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 10 Oct 2013 19:37:14 +0300 Subject: Recent changes in vdsmd startup In-Reply-To: <986640714.2530258.1381415894947.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> Message-ID: <5256D7BA.7030202@redhat.com> 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 >>> Arch at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >>> >> >> how will this affect the following use cases: >> >> 1. i added a new host to the system via the engine. >> at the end of the installation i expect the host to work without admin >> having to do any operation on the host. >> >> 2. i update a host to latest vdsm version via the engine. >> at the end of the update i expect the host to be updated without admin >> having to do any operation on the host >> > > Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. > The prints I copied above are relevant only if user tries to install and start vdsmd manually great. so how does backward compatibility work? i have a 3.2 engine, and i deploy latest vdsm due to some bug fixes. (i.e., i didn't get new host-deploy) From alonbl at redhat.com Thu Oct 10 16:38:19 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 10 Oct 2013 12:38:19 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <5256D7BA.7030202@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> Message-ID: <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> ----- 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 > >>> Arch at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/arch > >>> > >> > >> how will this affect the following use cases: > >> > >> 1. i added a new host to the system via the engine. > >> at the end of the installation i expect the host to work without admin > >> having to do any operation on the host. > >> > >> 2. i update a host to latest vdsm version via the engine. > >> at the end of the update i expect the host to be updated without admin > >> having to do any operation on the host > >> > > > > Of course it shouldn't effect any of the deploy process. If using the > > host-deploy, the host-deploy process should take care of stopping, > > starting and other managing that can be required before starting vdsmd, > > and it is taking care of. > > The prints I copied above are relevant only if user tries to install and > > start vdsmd manually > > great. so how does backward compatibility work? i have a 3.2 engine, and > i deploy latest vdsm due to some bug fixes. > (i.e., i didn't get new host-deploy) 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 at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From iheim at redhat.com Thu Oct 10 16:39:35 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 10 Oct 2013 19:39:35 +0300 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> Message-ID: <5256D847.7060409@redhat.com> 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 >>>>> Arch at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/arch >>>>> >>>> >>>> how will this affect the following use cases: >>>> >>>> 1. i added a new host to the system via the engine. >>>> at the end of the installation i expect the host to work without admin >>>> having to do any operation on the host. >>>> >>>> 2. i update a host to latest vdsm version via the engine. >>>> at the end of the update i expect the host to be updated without admin >>>> having to do any operation on the host >>>> >>> >>> Of course it shouldn't effect any of the deploy process. If using the >>> host-deploy, the host-deploy process should take care of stopping, >>> starting and other managing that can be required before starting vdsmd, >>> and it is taking care of. >>> The prints I copied above are relevant only if user tries to install and >>> start vdsmd manually >> >> great. so how does backward compatibility work? i have a 3.2 engine, and >> i deploy latest vdsm due to some bug fixes. >> (i.e., i didn't get new host-deploy) > > 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 at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >> From alonbl at redhat.com Thu Oct 10 16:43:40 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 10 Oct 2013 12:43:40 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <5256D847.7060409@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> Message-ID: <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> ----- 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 > >>>>> Arch at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/arch > >>>>> > >>>> > >>>> how will this affect the following use cases: > >>>> > >>>> 1. i added a new host to the system via the engine. > >>>> at the end of the installation i expect the host to work without admin > >>>> having to do any operation on the host. > >>>> > >>>> 2. i update a host to latest vdsm version via the engine. > >>>> at the end of the update i expect the host to be updated without admin > >>>> having to do any operation on the host > >>>> > >>> > >>> Of course it shouldn't effect any of the deploy process. If using the > >>> host-deploy, the host-deploy process should take care of stopping, > >>> starting and other managing that can be required before starting vdsmd, > >>> and it is taking care of. > >>> The prints I copied above are relevant only if user tries to install and > >>> start vdsmd manually > >> > >> great. so how does backward compatibility work? i have a 3.2 engine, and > >> i deploy latest vdsm due to some bug fixes. > >> (i.e., i didn't get new host-deploy) > > > > 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 at lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >> > > From iheim at redhat.com Thu Oct 10 16:45:36 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 10 Oct 2013 19:45:36 +0300 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> Message-ID: <5256D9B0.2080400@redhat.com> 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 >>>>>>> Arch at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/arch >>>>>>> >>>>>> >>>>>> how will this affect the following use cases: >>>>>> >>>>>> 1. i added a new host to the system via the engine. >>>>>> at the end of the installation i expect the host to work without admin >>>>>> having to do any operation on the host. >>>>>> >>>>>> 2. i update a host to latest vdsm version via the engine. >>>>>> at the end of the update i expect the host to be updated without admin >>>>>> having to do any operation on the host >>>>>> >>>>> >>>>> Of course it shouldn't effect any of the deploy process. If using the >>>>> host-deploy, the host-deploy process should take care of stopping, >>>>> starting and other managing that can be required before starting vdsmd, >>>>> and it is taking care of. >>>>> The prints I copied above are relevant only if user tries to install and >>>>> start vdsmd manually >>>> >>>> great. so how does backward compatibility work? i have a 3.2 engine, and >>>> i deploy latest vdsm due to some bug fixes. >>>> (i.e., i didn't get new host-deploy) >>> >>> 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 at lists.fedorahosted.org >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>> >> >> From alonbl at redhat.com Thu Oct 10 16:47:58 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 10 Oct 2013 12:47:58 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <5256D9B0.2080400@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> Message-ID: <10021839.2594495.1381423678991.JavaMail.root@redhat.com> ----- 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 > >>>>>>> Arch at ovirt.org > >>>>>>> http://lists.ovirt.org/mailman/listinfo/arch > >>>>>>> > >>>>>> > >>>>>> how will this affect the following use cases: > >>>>>> > >>>>>> 1. i added a new host to the system via the engine. > >>>>>> at the end of the installation i expect the host to work without admin > >>>>>> having to do any operation on the host. > >>>>>> > >>>>>> 2. i update a host to latest vdsm version via the engine. > >>>>>> at the end of the update i expect the host to be updated without admin > >>>>>> having to do any operation on the host > >>>>>> > >>>>> > >>>>> Of course it shouldn't effect any of the deploy process. If using the > >>>>> host-deploy, the host-deploy process should take care of stopping, > >>>>> starting and other managing that can be required before starting vdsmd, > >>>>> and it is taking care of. > >>>>> The prints I copied above are relevant only if user tries to install > >>>>> and > >>>>> start vdsmd manually > >>>> > >>>> great. so how does backward compatibility work? i have a 3.2 engine, and > >>>> i deploy latest vdsm due to some bug fixes. > >>>> (i.e., i didn't get new host-deploy) > >>> > >>> 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. """ > > > > > 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 at lists.fedorahosted.org > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>> > >> > >> > > From iheim at redhat.com Thu Oct 10 17:33:39 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 10 Oct 2013 20:33:39 +0300 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <10021839.2594495.1381423678991.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256B8A8.5070007@redhat.com> <986640714.2530258.1381415894947.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> Message-ID: <5256E4F3.3010402@redhat.com> 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 >>>>>>>>> Arch at ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch >>>>>>>>> >>>>>>>> >>>>>>>> how will this affect the following use cases: >>>>>>>> >>>>>>>> 1. i added a new host to the system via the engine. >>>>>>>> at the end of the installation i expect the host to work without admin >>>>>>>> having to do any operation on the host. >>>>>>>> >>>>>>>> 2. i update a host to latest vdsm version via the engine. >>>>>>>> at the end of the update i expect the host to be updated without admin >>>>>>>> having to do any operation on the host >>>>>>>> >>>>>>> >>>>>>> Of course it shouldn't effect any of the deploy process. If using the >>>>>>> host-deploy, the host-deploy process should take care of stopping, >>>>>>> starting and other managing that can be required before starting vdsmd, >>>>>>> and it is taking care of. >>>>>>> The prints I copied above are relevant only if user tries to install >>>>>>> and >>>>>>> start vdsmd manually >>>>>> >>>>>> great. so how does backward compatibility work? i have a 3.2 engine, and >>>>>> i deploy latest vdsm due to some bug fixes. >>>>>> (i.e., i didn't get new host-deploy) >>>>> >>>>> 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. >>> >>>> >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> vdsm-devel mailing list >>>>>> vdsm-devel at lists.fedorahosted.org >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>>>> >>>> >>>> >> >> From alonbl at redhat.com Thu Oct 10 17:51:00 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 10 Oct 2013 13:51:00 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <5256E4F3.3010402@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> Message-ID: <352425288.2607621.1381427460154.JavaMail.root@redhat.com> ----- 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 > >>>>>>>>> Arch at ovirt.org > >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch > >>>>>>>>> > >>>>>>>> > >>>>>>>> how will this affect the following use cases: > >>>>>>>> > >>>>>>>> 1. i added a new host to the system via the engine. > >>>>>>>> at the end of the installation i expect the host to work without > >>>>>>>> admin > >>>>>>>> having to do any operation on the host. > >>>>>>>> > >>>>>>>> 2. i update a host to latest vdsm version via the engine. > >>>>>>>> at the end of the update i expect the host to be updated without > >>>>>>>> admin > >>>>>>>> having to do any operation on the host > >>>>>>>> > >>>>>>> > >>>>>>> Of course it shouldn't effect any of the deploy process. If using the > >>>>>>> host-deploy, the host-deploy process should take care of stopping, > >>>>>>> starting and other managing that can be required before starting > >>>>>>> vdsmd, > >>>>>>> and it is taking care of. > >>>>>>> The prints I copied above are relevant only if user tries to install > >>>>>>> and > >>>>>>> start vdsmd manually > >>>>>> > >>>>>> great. so how does backward compatibility work? i have a 3.2 engine, > >>>>>> and > >>>>>> i deploy latest vdsm due to some bug fixes. > >>>>>> (i.e., i didn't get new host-deploy) > >>>>> > >>>>> This was already supported in last iteration. > >>>>> > >>>>> The init.d and systemd script support reconfigure verb that is executed > >>>>> ever since vdsm-bootstrap, these are kept for backward compatibility. > >>>> > >>>> so what happens to 3.2 engine with this new vdsm, without this patch? > >>>> http://gerrit.ovirt.org/20102 > >>> > >>> this patch is just adjustment to whatever yaniv plans now. > >>> > >>> up until now host-deploy tried to execute vdsm-tool libvirt-configure and > >>> if fails it tries the old way as I described above. > >>> > >>> now host-deploy will be adjusted to call a single verb to configure > >>> whatever need to be configured by vdsm. > >> > >> so what happens if the vdsm on the host is an older vdsm? > > > > I don't follow... > > """ > >>> up until now host-deploy tried to execute vdsm-tool libvirt-configure and > >>> if fails it tries the old way as I described above. > > """ > > yes. but the new host-deploy will not do the fallback iiuc? > fallback is relevant only for the component which knows legacy and new methods which is the new host-deploy (1.1). > > > >> > >>> > >>> waiting for interface of vdsm-tool to stabilize before attempting to fix. > >>> > >>> 3.2, 3.1, 3.0 uses the old method of reconfigure, it does not use vdsm > >>> tool. > >>> > >>>> > >>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> vdsm-devel mailing list > >>>>>> vdsm-devel at lists.fedorahosted.org > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>>>> > >>>> > >>>> > >> > >> > > From danken at redhat.com Thu Oct 10 20:34:10 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 10 Oct 2013 21:34:10 +0100 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <352425288.2607621.1381427460154.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D7BA.7030202@redhat.com> <1479804318.2591825.1381423099580.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> <352425288.2607621.1381427460154.JavaMail.root@redhat.com> Message-ID: <20131010203410.GC26799@redhat.com> 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 > > >>>>>>>>> Arch at ovirt.org > > >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> how will this affect the following use cases: > > >>>>>>>> > > >>>>>>>> 1. i added a new host to the system via the engine. > > >>>>>>>> at the end of the installation i expect the host to work without > > >>>>>>>> admin > > >>>>>>>> having to do any operation on the host. > > >>>>>>>> > > >>>>>>>> 2. i update a host to latest vdsm version via the engine. > > >>>>>>>> at the end of the update i expect the host to be updated without > > >>>>>>>> admin > > >>>>>>>> having to do any operation on the host 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. From asegurap at redhat.com Thu Oct 10 20:40:36 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Thu, 10 Oct 2013 16:40:36 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <20131010203410.GC26799@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> <352425288.2607621.1381427460154.JavaMail.root@redhat.com> <20131010203410.GC26799@redhat.com> Message-ID: <1195546153.2654337.1381437636952.JavaMail.root@redhat.com> 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-restart' > > > >>>>>>>>> you > > > >>>>>>>>> are > > > >>>>>>>>> ready to start vdsmd again as usual. > > > >>>>>>>>> > > > >>>>>>>>> All those vdsm-tool commands require root privileges, otherwise > > > >>>>>>>>> it'll > > > >>>>>>>>> alert > > > >>>>>>>>> and stop the operation. > > > >>>>>>>>> Over systemd the errors\output can be watched in > > > >>>>>>>>> /var/log/messages > > > >>>>>>>>> > > > >>>>>>>>> Thanks, > > > >>>>>>>>> Yaniv Bronhaim. > > > >>>>>>>>> _______________________________________________ > > > >>>>>>>>> Arch mailing list > > > >>>>>>>>> Arch at ovirt.org > > > >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/arch > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>>> how will this affect the following use cases: > > > >>>>>>>> > > > >>>>>>>> 1. i added a new host to the system via the engine. > > > >>>>>>>> at the end of the installation i expect the host to work without > > > >>>>>>>> admin > > > >>>>>>>> having to do any operation on the host. > > > >>>>>>>> > > > >>>>>>>> 2. i update a host to latest vdsm version via the engine. > > > >>>>>>>> at the end of the update i expect the host to be updated without > > > >>>>>>>> admin > > > >>>>>>>> having to do any operation on the host > > 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 at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From danken at redhat.com Thu Oct 10 20:51:30 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 10 Oct 2013 21:51:30 +0100 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <1195546153.2654337.1381437636952.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D847.7060409@redhat.com> <1417742590.2593444.1381423420542.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> <352425288.2607621.1381427460154.JavaMail.root@redhat.com> <20131010203410.GC26799@redhat.com> <1195546153.2654337.1381437636952.JavaMail.root@redhat.com> Message-ID: <20131010205130.GI26799@redhat.com> 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. From ybronhei at redhat.com Sat Oct 12 21:26:53 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Sat, 12 Oct 2013 17:26:53 -0400 (EDT) Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <20131010205130.GI26799@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> <352425288.2607621.1381427460154.JavaMail.root@redhat.com> <20131010203410.GC26799@redhat.com> <1195546153.2654337.1381437636952.JavaMail.root@redhat.com> <20131010205130.GI26799@redhat.com> Message-ID: <1579425482.3332561.1381613213693.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Antoni Segura Puimedon" > Cc: "arch" , "VDSM Project Development" > Sent: Thursday, October 10, 2013 11:51:30 PM > Subject: 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. Interesting point. Thanks for raising that up, raising such issues was part of this mail goals You are right that after an upgrade we will need to restart libvirt service manually to start working with new configuration, But, AFAIK we don't force vdsmd restart after upgrading. If the user updated the package and still wants the new configuration, manual vdsmd restart will be required anyway. So the print to restart also related service is just enough. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From danken at redhat.com Sun Oct 13 07:13:09 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Sun, 13 Oct 2013 08:13:09 +0100 Subject: [vdsm] Recent changes in vdsmd startup In-Reply-To: <1579425482.3332561.1381613213693.JavaMail.root@redhat.com> References: <1981186977.2503303.1381411967466.JavaMail.root@redhat.com> <5256D9B0.2080400@redhat.com> <10021839.2594495.1381423678991.JavaMail.root@redhat.com> <5256E4F3.3010402@redhat.com> <352425288.2607621.1381427460154.JavaMail.root@redhat.com> <20131010203410.GC26799@redhat.com> <1195546153.2654337.1381437636952.JavaMail.root@redhat.com> <20131010205130.GI26799@redhat.com> <1579425482.3332561.1381613213693.JavaMail.root@redhat.com> Message-ID: <20131013071309.GA18232@redhat.com> On Sat, Oct 12, 2013 at 05:26:53PM -0400, Yaniv Bronheim wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" > > To: "Antoni Segura Puimedon" > > Cc: "arch" , "VDSM Project Development" > > Sent: Thursday, October 10, 2013 11:51:30 PM > > Subject: 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. > > Interesting point. Thanks for raising that up, raising such issues was part of this mail goals > You are right that after an upgrade we will need to restart libvirt service manually to start working with new configuration, > But, AFAIK we don't force vdsmd restart after upgrading. Actually, we have to restart (you cannot expect the old process to keep on running porperly after its data/code files have changed underneath) and we do, by virtue of /sbin/service vdsmd condrestart in the %post script. > If the user updated the package and still wants the new configuration, > manual vdsmd restart will be required anyway. So the print to restart also related service is just enough. I'm afraid we're ain't so lucky... Dan. From smizrahi at redhat.com Sun Oct 13 08:38:00 2013 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Sun, 13 Oct 2013 04:38:00 -0400 (EDT) Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer In-Reply-To: <20131009115503.GF15427@redhat.com> References: <20131009115503.GF15427@redhat.com> Message-ID: <2103638794.1279218.1381653480149.JavaMail.root@redhat.com> Yaniv has a keen eye for catching system breaking failures and I think he'll be an invaluable addition to the stable branch management. +1 ----- Original Message ----- > From: "Dan Kenigsberg" > To: vdsm-devel at fedorahosted.org, arch at ovirt.org > Sent: Wednesday, October 9, 2013 2:55:03 PM > Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer > > Recently, the Vdsm branch ovirt-3.3 was rebased on a > relatively-stabilized vdsm-4.13.0. > > As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large > micro version. Plenty of bug fixes are expected to be suggested to this > branch. > > Currently, Federico is responsible to merge patches for oVirt-3.3.1, > with my assistance. I would like to nominate Yaniv to join us in this > delicate task: on one hand we should fix as many problems, but on the > other hand - avoid regressions and needless surprises. It is a micro > version after all. > > Yaniv has a wide understanding of Vdsm internals, and I am certain he > would know how to solve problems introduced by patches approved by him. > > Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. > > Dan. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From mlipchuk at redhat.com Sun Oct 13 13:41:13 2013 From: mlipchuk at redhat.com (Maor Lipchuk) Date: Sun, 13 Oct 2013 16:41:13 +0300 Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer In-Reply-To: <20131009115503.GF15427@redhat.com> References: <20131009115503.GF15427@redhat.com> Message-ID: <525AA2F9.3090108@redhat.com> +1 On 10/09/2013 02:55 PM, Dan Kenigsberg wrote: > Recently, the Vdsm branch ovirt-3.3 was rebased on a > relatively-stabilized vdsm-4.13.0. > > As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large > micro version. Plenty of bug fixes are expected to be suggested to this > branch. > > Currently, Federico is responsible to merge patches for oVirt-3.3.1, > with my assistance. I would like to nominate Yaniv to join us in this > delicate task: on one hand we should fix as many problems, but on the > other hand - avoid regressions and needless surprises. It is a micro > version after all. > > Yaniv has a wide understanding of Vdsm internals, and I am certain he > would know how to solve problems introduced by patches approved by him. > > Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. > > Dan. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Sun Oct 13 17:21:01 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 13 Oct 2013 20:21:01 +0300 Subject: [vdsm] suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer In-Reply-To: <525AA2F9.3090108@redhat.com> References: <20131009115503.GF15427@redhat.com> <525AA2F9.3090108@redhat.com> Message-ID: <525AD67D.1090709@redhat.com> On 10/13/2013 04:41 PM, Maor Lipchuk wrote: > +1 > > On 10/09/2013 02:55 PM, Dan Kenigsberg wrote: >> Recently, the Vdsm branch ovirt-3.3 was rebased on a >> relatively-stabilized vdsm-4.13.0. >> >> As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large >> micro version. Plenty of bug fixes are expected to be suggested to this >> branch. >> >> Currently, Federico is responsible to merge patches for oVirt-3.3.1, >> with my assistance. I would like to nominate Yaniv to join us in this >> delicate task: on one hand we should fix as many problems, but on the >> other hand - avoid regressions and needless surprises. It is a micro >> version after all. >> >> Yaniv has a wide understanding of Vdsm internals, and I am certain he >> would know how to solve problems introduced by patches approved by him. >> >> Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. >> >> Dan. >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > yaniv was added as vdsm stable branch maintainer (together with danken and federico) From bob at doolittle.us.com Sun Oct 13 18:49:47 2013 From: bob at doolittle.us.com (Bob) Date: Sun, 13 Oct 2013 11:49:47 -0700 Subject: Thin Client connection brokering (VDI) Message-ID: <525AEB4B.4080609@doolittle.us.com> Hi, I'm exploring thin client connections to oVirt in a VDI context, and after having read the overviews I've found I still have some questions, and hope you can point me to the right place for more information. It appears that oVirt supports a VDI model where thin client sessions can be load balanced to a set of VMs, or directed to VMs with existing sessions for the user. Is this correct? At what level of the architecture does the connection brokering take place (i.e. where is it determined which VM a thin client should be connected to, and what pieces of the system are involved)? Can it work for both VNC and SPICE based clients? If a developer were interested in adding support for connection brokering of new thin client protocols, where would they start looking? Pointers to relevant documentation or mailing lists would be much appreciated. Is this more of an engine or a node question (or does it span both)? Thanks! -Bob Doolittle From sbonazzo at redhat.com Tue Oct 15 12:32:29 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Tue, 15 Oct 2013 14:32:29 +0200 Subject: Migrating an existing installation to hosted engine Message-ID: <525D35DD.8040201@redhat.com> Hi, migrating an existing installation to hosted engine may be done in several ways. The first way may be using p2v, creating a VM from the physical host in an existing export domain. Then creating an OVF of the VM will allow hosted engine setup to import it. Fedora seems to have all needed packages, I've not verified it on CentOS. If I've understood correctly how it works, the required packages are: On Fedora >= 20: rubygem-virt-p2v-0.9.0-4.fc20 http://koji.fedoraproject.org/koji/buildinfo?buildID=453540 providing the client on >20 It's designed to be run from a live iso, not to be installed on an host On Fedora <= 20: virt-v2v (not sure if needed also on >20 but it seems so) providing the client and server on <= 20 provides the p2v server, receive data from v2v/p2v and save them on the export domain. However we need to test the whole process in order to be sure on requirements. Cons: - I don't think it will work if the export domain is on the same host we're going to convert to a VM. This may be solved with a release note telling the user to use another export domain. - The host running engine may also be used fot iso domain storage. p2v may generate a quite big image of the physical host, moving a storage domain to a VM. We can warn the user about it or add a release note. - if the physical host is an all-in-one system, migrating it as-is inside a VM need to use it as nested VM, and I'm not sure if it works at all with the hosted engine VM. Maybe such kind of migration will never be supported. Pros: - it will preserve the host configuration, including FQDN, firewall, database and so on. The second way is just create a fresh new hosted engine VM, backup everything needed from the physical host and then restore it inside the new VM Cons: - you've to install a new system and a new engine and anything else you wanted to migrate to the VM - you've to do the backup / restore instead of having already everything in place - you've to set FQDN and other configs manually - It will not handle the host name if the VM and you'd still need to add the hypervisor and then deal with it again after the restore part. Pros: - the VM may be smaller - the environment will be clean - the storage may stay on physical host and not migrated in a VM Maybe we can start with the p2v solution for 3.3 and look at the backup/restore for 3.4. What do you think? Thoughts and comments are welcome. Thank you, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From iheim at redhat.com Wed Oct 16 00:02:30 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 15 Oct 2013 20:02:30 -0400 Subject: Thin Client connection brokering (VDI) In-Reply-To: <525AEB4B.4080609@doolittle.us.com> References: <525AEB4B.4080609@doolittle.us.com> Message-ID: <525DD796.2030302@redhat.com> On 10/13/2013 02:49 PM, Bob wrote: > Hi, > > I'm exploring thin client connections to oVirt in a VDI context, and > after having read the overviews I've found I still have some questions, > and hope you can point me to the right place for more information. > > It appears that oVirt supports a VDI model where thin client sessions > can be load balanced to a set of VMs, or directed to VMs with existing > sessions for the user. Is this correct? they can get a VM from a pool or a specific VM. > > At what level of the architecture does the connection brokering take > place (i.e. where is it determined which VM a thin client should be > connected to, and what pieces of the system are involved)? Can it work > for both VNC and SPICE based clients? vnc, spice or rdp. rdp is to the guest. vnc and spice to the host, or for spice via a proxy, or for novnc/spice.html5 via a websocket proxy. > > If a developer were interested in adding support for connection > brokering of new thin client protocols, where would they start looking? can you elaborate on which protocol? is it to the host (qemu), or to the guest? > > Pointers to relevant documentation or mailing lists would be much > appreciated. Is this more of an engine or a node question (or does it > span both)? > > Thanks! > > -Bob Doolittle > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From iheim at redhat.com Wed Oct 16 11:01:16 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 Oct 2013 07:01:16 -0400 Subject: oVirt October Updates Message-ID: <525E71FC.4000101@redhat.com> Hope to meet many next week in LinuxCon Europe/KVM Forum/oVirt conference in Edinburgh Highlights: - oVirt 3.3 GA of course! some links covering it[10] - more links in Russian, Japanese, German and Italian [15] - oVirt 3.3.1 nearing beta this will include a slew of bug fixes, and a few items which missed 3.3. - Malini Rao sent a proposal for some UI changes[4] - some pluggable scheduler samples are available[5] - Summarized 3.4 community requests, hope the top ones will make it to 3.4[6] - 3.4 cycle - planned to be a shorter cycle, trying to make features available faster. - Ren? Koch published version 0.1 of Monitoring UI-Plugin[8] - a new oVirt module merged to Ansible - covers VM life cycle (create/start/stop/etc.) [11] - a puppet module to deploy ovirt engine and ovirt node[12] - and a chef one[14] (both by Jason Cannon) Conferences: - LinuxCon Europe/KVM Forum/oVirt - next week in Edinburgh LOTs of sessions: http://www.ovirt.org/KVM_Forum_2013 - FOSDEM 2014 - We will be co-organizing a "Virtualization and IaaS" DevRoom with +Lars Kurth, +Itamar Heim and +Thierry Carrez as DevRoom organizers - past: Open World Forum - Building an open hybrid cloud with open source[13] K-LUG - Rochester, MN Area Linux Users Group - oVirt intro[16] Other: - a 3 part series by Humble on using the python sdk: How to shutdown/stop or start virtual machines (VMs) in ovirt DC automatically?[1] List Datacenter, hypervisors/host,vms in an ovirt DC with its name,status,id..etc[2] Find out hosts and clusters where vm is running. its status, ids, storage domain details in an ovirt dc[3] - another one by Humble: Convert physical/virtual systems to virtual using virt-p2v && virt-v2v then use it in ovirt DC[7] - LINBIT published "High-Availability oVirt-Cluster with iSCSI-Storage"[9] Have Fun, Itamar [1] http://humblec.com/ovirt-shutdownstop-start-virtual-machines-vms-ovirt-dc-automatically-using-python-sdk/ [2] http://humblec.com/ovirt-list-datacenter-hypervisorshostvms-ovirt-dc-status-using-pythonovirt-sdk-part-2/ [3] http://humblec.com/ovirt-find-hosts-clusters-vm-running-status-ids-storage-domain-details-ovirt-dc-pythonovirt-sdk-part-3/ [4] http://lists.ovirt.org/pipermail/users/2013-October/017088.html [5] http://gerrit.ovirt.org/gitweb?p=ovirt-scheduler-proxy.git;a=tree;f=plugins/examples [6] http://lists.ovirt.org/pipermail/users/2013-October/016898.html [7] http://humblec.com/convert-physical-virtual-virtual-using-virt-v2v-virt-p2v-kvmovirt/ [8] http://lists.ovirt.org/pipermail/users/2013-October/016842.html [9] note: link requires registeration: http://www.linbit.com/en/company/news/333-high-available-virtualization-at-a-most-reasonable-price the pdf is: http://www.linbit.com/en/downloads/tech-guides?download=68:high-availability-ovirt-cluster-with-iscsi-storage [10] ovirt 3.3 ga links http://lists.ovirt.org/pipermail/announce/2013-September/000061.html http://www.ovirt.org/OVirt_3.3_release_announcement http://www.redhat.com/about/news/archive/2013/9/ovirt-3-3-release-brings-openstack-and-gluster-integration-to-premier-open-source-virtualization-management-project http://community.redhat.com/ovirt-3-3-glusterized/ http://community.redhat.com/ovirt-3-3-spices-up-the-software-defined-datacenter-with-openstack-and-gluster-integration/ http://www.tuicool.com/articles/eIJnMr http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MzQ http://captainkvm.com/2013/09/614/ http://www.vmwareindex.com/category/hadoop-splunk/openstack/ovirt-3-3-is-now-released http://thehyperadvisor.com/2013/09/17/ovirt-3-3-is-now-released/ [11] https://github.com/ansible/ansible/pull/3838 [12] http://forge.puppetlabs.com/jcannon/ovirt/0.0.1 [13] http://www.openworldforum.org/en/schedule/1/ http://www.openworldforum.org/en/speakers/49/ [14] http://community.opscode.com/cookbooks/ovirt [15] russian: http://www.opennet.ru/opennews/art.shtml?num=38000 http://ru.fedoracommunity.org/content/%D0%92%D1%8B%D1%88%D0%B5%D0%BB-ovirt-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8-33-%D0%B8-%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D0%B5-%D0%BD%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B8 http://linuxforum.ru/viewtopic.php?id=30572 http://citrix.pp.ru/news/2214-novaya-versiya-sistemy-upravleniya-infrastrukturoj-virtualizatsii-ovirt-3-3.html german: http://www.pro-linux.de/news/1/20258/ovirt-33-unterstuetzt-openstack.html japanese: http://en.sourceforge.jp/magazine/13/09/25/163000 italian: http://www.freeonline.org/cs/com/la-release-ovirt-3-3-integra-openstack-e-gluster-nel-progetto-di-gestione-della-virtualizzazione-open-source.html http://www.tomshw.it/cont/news/open-source-red-hat-gestisce-la-virtualizzazione/49564/1.html [16] http://k-lug.org/OldNews From mburns at redhat.com Wed Oct 16 14:36:27 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 16 Oct 2013 10:36:27 -0400 Subject: Release Schedule In-Reply-To: <525588A0.7040100@redhat.com> References: <52556FB4.5010406@redhat.com> <525588A0.7040100@redhat.com> Message-ID: <525EA46B.3070805@redhat.com> Adding this to arch list as well. On 10/09/2013 12:47 PM, Livnat Peer wrote: > On 10/09/2013 06:01 PM, Itamar Heim wrote: >> Our current release schedule is "~6 months". >> we've found this is a long cycle, causing: >> - time to deliver is long - no reason we can't stabilize chunks in >> shorter cycles. >> - the stabilization cycle is very long. >> >> I've proposed we trim down the schedule to 3-4 months for now, to reduce >> time to delivery and shorten the stabilization cycle. >> > > +1 > > I am all for it, I think shorter release cycles would also help us to > deliver fixes which are not critical but are still annoying faster to > oVirt users. > > > >> Thanks, >> Itamar >> _______________________________________________ >> Board mailing list >> Board at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/board > > _______________________________________________ > Board mailing list > Board at ovirt.org > http://lists.ovirt.org/mailman/listinfo/board > From bob at doolittle.us.com Wed Oct 16 16:36:53 2013 From: bob at doolittle.us.com (Bob Doolittle) Date: Wed, 16 Oct 2013 09:36:53 -0700 Subject: Thin Client connection brokering (VDI) In-Reply-To: <525DD796.2030302@redhat.com> References: <525AEB4B.4080609@doolittle.us.com> <525DD796.2030302@redhat.com> Message-ID: <525EC0A5.50106@doolittle.us.com> Let's think about building a SPICE-based thin client for a moment. What minimum set of basic capabilities would it require (i.e. how thin could it be) in order to get an experience similar to the User Portal: - authenticate - allocate a new VM from a Pool - select from existing VMs and then of course connect to the VM in question. It would clearly need more than just the SPICE protocol, since that's all about talking to the VM once it is running. What else? Most VDI models (e.g. VMware, Citrix, Sun Ray, etc) call this Connection Brokering or Session Brokering. They might have a simple GUI in the client to authenticate the user using some protocol to communicate to an authentication manager of some sort, and then they communicate via a protocol to the Broker to discover and finally connect to VMs. What's the model for a SPICE client? Thanks, Bob On 10/15/2013 05:02 PM, Itamar Heim wrote: > On 10/13/2013 02:49 PM, Bob wrote: >> Hi, >> >> I'm exploring thin client connections to oVirt in a VDI context, and >> after having read the overviews I've found I still have some questions, >> and hope you can point me to the right place for more information. >> >> It appears that oVirt supports a VDI model where thin client sessions >> can be load balanced to a set of VMs, or directed to VMs with existing >> sessions for the user. Is this correct? > > they can get a VM from a pool or a specific VM. > >> >> At what level of the architecture does the connection brokering take >> place (i.e. where is it determined which VM a thin client should be >> connected to, and what pieces of the system are involved)? Can it work >> for both VNC and SPICE based clients? > > vnc, spice or rdp. > rdp is to the guest. > vnc and spice to the host, or for spice via a proxy, or for > novnc/spice.html5 via a websocket proxy. > >> >> If a developer were interested in adding support for connection >> brokering of new thin client protocols, where would they start looking? > > can you elaborate on which protocol? is it to the host (qemu), or to > the guest? > >> >> Pointers to relevant documentation or mailing lists would be much >> appreciated. Is this more of an engine or a node question (or does it >> span both)? >> >> Thanks! >> >> -Bob Doolittle >> >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Wed Oct 16 16:43:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 16 Oct 2013 12:43:20 -0400 Subject: Thin Client connection brokering (VDI) In-Reply-To: <525EC0A5.50106@doolittle.us.com> References: <525AEB4B.4080609@doolittle.us.com> <525DD796.2030302@redhat.com> <525EC0A5.50106@doolittle.us.com> Message-ID: <525EC228.3070004@redhat.com> On 10/16/2013 12:36 PM, Bob Doolittle wrote: > Let's think about building a SPICE-based thin client for a moment. What > minimum set of basic capabilities would it require (i.e. how thin could > it be) in order to get an experience similar to the User Portal: > - authenticate > - allocate a new VM from a Pool > - select from existing VMs > > and then of course connect to the VM in question. > > It would clearly need more than just the SPICE protocol, since that's > all about talking to the VM once it is running. What else? > > Most VDI models (e.g. VMware, Citrix, Sun Ray, etc) call this Connection > Brokering or Session Brokering. They might have a simple GUI in the > client to authenticate the user using some protocol to communicate to an > authentication manager of some sort, and then they communicate via a > protocol to the Broker to discover and finally connect to VMs. What's > the model for a SPICE client? well, connection brokering to me is if the session is brokered. in this case, you're mostly talking about adding to the client ability to choose the destination VM to connect to. maybe start/stop it. gnome-boxes is doing this from client side. we have sample user portals in java/ruby/python for the code you'd need[1] and the libgovirt for C which iirc is what gnome-boxes uses. does this cover the question/use case? thanks, Itamar [1]http://gerrit.ovirt.org/gitweb?p=samples-portals.git;a=tree > > Thanks, > Bob > > On 10/15/2013 05:02 PM, Itamar Heim wrote: >> On 10/13/2013 02:49 PM, Bob wrote: >>> Hi, >>> >>> I'm exploring thin client connections to oVirt in a VDI context, and >>> after having read the overviews I've found I still have some questions, >>> and hope you can point me to the right place for more information. >>> >>> It appears that oVirt supports a VDI model where thin client sessions >>> can be load balanced to a set of VMs, or directed to VMs with existing >>> sessions for the user. Is this correct? >> >> they can get a VM from a pool or a specific VM. >> >>> >>> At what level of the architecture does the connection brokering take >>> place (i.e. where is it determined which VM a thin client should be >>> connected to, and what pieces of the system are involved)? Can it work >>> for both VNC and SPICE based clients? >> >> vnc, spice or rdp. >> rdp is to the guest. >> vnc and spice to the host, or for spice via a proxy, or for >> novnc/spice.html5 via a websocket proxy. >> >>> >>> If a developer were interested in adding support for connection >>> brokering of new thin client protocols, where would they start looking? >> >> can you elaborate on which protocol? is it to the host (qemu), or to >> the guest? >> >>> >>> Pointers to relevant documentation or mailing lists would be much >>> appreciated. Is this more of an engine or a node question (or does it >>> span both)? >>> >>> Thanks! >>> >>> -Bob Doolittle >>> >>> _______________________________________________ >>> Arch mailing list >>> Arch at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >> > From mburns at redhat.com Sat Oct 19 11:26:06 2013 From: mburns at redhat.com (Mike Burns) Date: Sat, 19 Oct 2013 07:26:06 -0400 (EDT) Subject: Cancelled: oVirt Weekly Meeting Message-ID: <1886978988.10167760.1382181966507.JavaMail.root@redhat.com> A single instance of the following meeting has been cancelled: Subject: oVirt Weekly Meeting Organizer: "Mike Burns" Location: #ovirt of oftc.net Time: Wednesday, October 23, 2013, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern Required: danken at redhat.com; oschreib at redhat.com; ykaul at redhat.com; sgordon at redhat.com; dfediuck at redhat.com; Jon.Benedict at netapp.com; pmyers at redhat.com; simon at redhat.com; imad.sousou at intel.com; aliguori at us.ibm.com; lhawthor at redhat.com ... Optional: arch at ovirt.org; board at ovirt.org; menescu at cisco.com *~*~*~*~*~*~*~*~*~* Due to oVirt Developer Meetings at KVM Forum, this meeting is cancelled. If you have topics that would normally be discussed on the meeting, please follow up on email. Thanks Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 4187 bytes Desc: not available URL: From fabiand at redhat.com Mon Oct 21 17:45:41 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 21 Oct 2013 19:45:41 +0200 Subject: Needed: Node and Engine cooperation Message-ID: <1382377541.2828.45.camel@fdeutsch-laptop.local> Hey, with the extraction of the oVirt Engine / VDSM specific bits from Node in it's 3.0 release, oVirt Node became unaware of when it is being managed. Pre-3.0 Node (it's TUI) had specific knowledge about what configuration files existed when it was registered to Engine. This is not the case in Node 3.0 anymore. And this leads to problems. E.g. a user removing Engines network layout. A new way is needed to pass informations between the management instance and Node's core. This informations are needed e.g. to prevent the user from accidentally destroying Engines network layout on a Node. I've opened a bug [0] to suggest a way of sharing this kind of informations. The idea is that Node and the management instance - Engine - share a set of common configuration keys in /etc/default/ovirt to pass the relevant bit's to Node. For now I thought about this three keys: OVIRT_MANAGED_BY= This key is used to (a) signal the Node is being managed and (b) signaling who is managing this node. OVIRT_MANAGED_IFNAMES=[,,...] This key is used to specify a number (comma separated list) of ifnames which are managed and for which the TUI shall display some information (IP, ...). This can also be used by the TUI to decide to not offer NIC configuration to the user. OVIRT_MANAGED_LOCKED_PAGES=[,,...] (Future) A list of pages which shall be locked e.g. because the management instance is configuring the aspect (e.g. networking or logging). The third one (OVIRT_MANAGED_LOCKED_PAGES) needs a tighter integration and might be relevant in the future, but the first two should really be implemented quickly for the reasons given above. It is quit elate in the development process but probably worth to think about getting this into 3.3.1, to prevent all sorts of (accidentally) user-driven collisions between Node and Engine. Thoughts? Greetings fabian --- [0] https://bugzilla.redhat.com/show_bug.cgi?id=1021647 From iheim at redhat.com Tue Oct 22 20:55:00 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 22 Oct 2013 21:55:00 +0100 Subject: CfP: Virtualisation and IaaS DevRoom at FOSDEM'14 Message-ID: <5266E624.3050506@redhat.com> https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom Call for Participation The scope for this devroom is open source, openly-developed projects in the areas of virtualisation and IaaS type clouds, ranging from low level to data center, up to cloud management platforms and cloud resource orchestration. Sessions should always target a developer audience. Bonus points for collaborative sessions that would be appealing to developers from multiple projects. We are particularly interested in the following themes: - low level virtualisation aspects - new features in classic and container-based virtualisation technologies - new use cases for virtualisation, such as virtualisation in mobile, automotive and embedded in general - other resource virtualisation technologies: networking, storage, ? - deep technical dives into specific IaaS or virtualisation management projects features - relationship between IaaS projects and specific dependencies (not just virtualisation) - integration and development leveraging solutions from multiple projects Important dates Submission deadline: Sunday, December 1st, 2013 Acceptance notifications: Sunday, December 15th, 2013 Final schedule announcement: Friday January 10th, 2014 Devroom @ FOSDEM'14: February 1st & 2nd, 2014 Practical Submissions should be 40 minutes, and consist of a 30 minute presentation with 10 minutes of Q&A or 40 minutes of discussions (e.g., requests for feedback, open discussions, etc.). Interactivity is encouraged, but optional. Talks are in English only. We do not provide travel assistance or reimbursement of travel expenses for accepted speakers. Submissions should be made via the FOSDEM submission page at https://penta.fosdem.org/submission/FOSDEM14 : - If necessary, create a Pentabarf account and activate it - In the ?Person? section, provide First name, Last name (in the ?General? tab), Email (in the ?Contact? tab) and Bio (?Abstract? field in the ?Description? tab) - Submit a proposal by clicking on ?Create event" - Important! Select the "Virtualisation and IaaS" track (on the ?General? tab) - Provide the title of your talk (?Event title? in the ?General? tab) - Provide a 250-word description of the subject of the talk and the intended audience (in the ?Abstract? field of the ?Description? tab) - Provide a rough outline of the talk or goals of the session (a short list of bullet points covering topics that will be discussed) in the ?Full description? field in the ?Description? tab Contact For questions w.r.t. the Virtualisation and IaaS DevRoom at FOSDEM'14, please contact the organizers via fosdem14-virt-and-iaas-devroom at googlegroups.com (or via https://groups.google.com/forum/#!forum/fosdem14-virt-and-iaas-devroom). From masayag at redhat.com Sun Oct 27 10:58:06 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 27 Oct 2013 06:58:06 -0400 (EDT) Subject: [node-devel] Needed: Node and Engine cooperation In-Reply-To: <1382377541.2828.45.camel@fdeutsch-laptop.local> References: <1382377541.2828.45.camel@fdeutsch-laptop.local> Message-ID: <1511837625.14165477.1382871486005.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "arch" , "node-devel" > Sent: Monday, October 21, 2013 8:45:41 PM > Subject: [node-devel] Needed: Node and Engine cooperation > > Hey, > > with the extraction of the oVirt Engine / VDSM specific bits from Node > in it's 3.0 release, oVirt Node became unaware of when it is being > managed. > Pre-3.0 Node (it's TUI) had specific knowledge about what configuration > files existed when it was registered to Engine. This is not the case in > Node 3.0 anymore. And this leads to problems. E.g. a user removing > Engines network layout. > > A new way is needed to pass informations between the management instance > and Node's core. This informations are needed e.g. to prevent the user > from accidentally destroying Engines network layout on a Node. How is it different from an admin connecting to non ovirt-node host and manually dis-configure its network ? I'm not sure we need to prevent from the administrator to perform any manual changes on the host. Perhaps the TUI could reflect the networks name by querying vdsm/libvirt in the same sense as the engine does so the user will be aware which interfaces carry logical networks. > > I've opened a bug [0] to suggest a way of sharing this kind of > informations. > > The idea is that Node and the management instance - Engine - share a set > of common configuration keys in /etc/default/ovirt to pass the relevant > bit's to Node. > For now I thought about this three keys: > > > OVIRT_MANAGED_BY= > This key is used to (a) signal the Node is being managed and (b) > signaling who is managing this node. > > OVIRT_MANAGED_IFNAMES=[,,...] > This key is used to specify a number (comma separated list) of ifnames > which are managed and for which the TUI shall display some information > (IP, ...). > This can also be used by the TUI to decide to not offer NIC > configuration to the user. > > OVIRT_MANAGED_LOCKED_PAGES=[,,...] > (Future) A list of pages which shall be locked e.g. because the > management instance is configuring the aspect (e.g. networking or > logging). > > > The third one (OVIRT_MANAGED_LOCKED_PAGES) needs a tighter integration > and might be relevant in the future, but the first two should really be > implemented quickly for the reasons given above. > > It is quit elate in the development process but probably worth to think > about getting this into 3.3.1, to prevent all sorts of (accidentally) > user-driven collisions between Node and Engine. > > Thoughts? > > Greetings > fabian > > --- > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1021647 > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From fabiand at redhat.com Sun Oct 27 12:06:06 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Sun, 27 Oct 2013 13:06:06 +0100 Subject: [node-devel] Needed: Node and Engine cooperation In-Reply-To: <1511837625.14165477.1382871486005.JavaMail.root@redhat.com> References: <1382377541.2828.45.camel@fdeutsch-laptop.local> <1511837625.14165477.1382871486005.JavaMail.root@redhat.com> Message-ID: <1382875566.3143.15.camel@fdeutsch-laptop.local> Am Sonntag, den 27.10.2013, 06:58 -0400 schrieb Moti Asayag: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "arch" , "node-devel" > > Sent: Monday, October 21, 2013 8:45:41 PM > > Subject: [node-devel] Needed: Node and Engine cooperation > > > > Hey, > > > > with the extraction of the oVirt Engine / VDSM specific bits from Node > > in it's 3.0 release, oVirt Node became unaware of when it is being > > managed. > > Pre-3.0 Node (it's TUI) had specific knowledge about what configuration > > files existed when it was registered to Engine. This is not the case in > > Node 3.0 anymore. And this leads to problems. E.g. a user removing > > Engines network layout. > > > > A new way is needed to pass informations between the management instance > > and Node's core. This informations are needed e.g. to prevent the user > > from accidentally destroying Engines network layout on a Node. > > How is it different from an admin connecting to non ovirt-node host and manually > dis-configure its network ? You are right that there is not really a difference between those both scenarios. If vdsm can cope with this then this shouldn't be a problem. My assumption was that vdsm had problems when the network configuration got changed on a different way than through vdsm. If vdsm is fine with this - the network configuration changed by the user - then this is fine and we don't have a problem. > I'm not sure we need to prevent from the administrator to perform any manual > changes on the host. Perhaps the TUI could reflect the networks name by querying > vdsm/libvirt in the same sense as the engine does so the user will be aware which > interfaces carry logical networks. The problem here is that the TUI is not aware of vdsm. That's why I suggest that VDSM is publishing these informations through e.g. the mechanism which is mentioned in [0] or also maybe through http://wiki.ovirt.org/Features/Node/FeaturePublishing Greetings fabian > > > > I've opened a bug [0] to suggest a way of sharing this kind of > > informations. > > > > The idea is that Node and the management instance - Engine - share a set > > of common configuration keys in /etc/default/ovirt to pass the relevant > > bit's to Node. > > For now I thought about this three keys: > > > > > > OVIRT_MANAGED_BY= > > This key is used to (a) signal the Node is being managed and (b) > > signaling who is managing this node. > > > > OVIRT_MANAGED_IFNAMES=[,,...] > > This key is used to specify a number (comma separated list) of ifnames > > which are managed and for which the TUI shall display some information > > (IP, ...). > > This can also be used by the TUI to decide to not offer NIC > > configuration to the user. > > > > OVIRT_MANAGED_LOCKED_PAGES=[,,...] > > (Future) A list of pages which shall be locked e.g. because the > > management instance is configuring the aspect (e.g. networking or > > logging). > > > > > > The third one (OVIRT_MANAGED_LOCKED_PAGES) needs a tighter integration > > and might be relevant in the future, but the first two should really be > > implemented quickly for the reasons given above. > > > > It is quit elate in the development process but probably worth to think > > about getting this into 3.3.1, to prevent all sorts of (accidentally) > > user-driven collisions between Node and Engine. > > > > Thoughts? > > > > Greetings > > fabian > > > > --- > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1021647 > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > > From danken at redhat.com Mon Oct 28 00:39:48 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 28 Oct 2013 00:39:48 +0000 Subject: [node-devel] Needed: Node and Engine cooperation In-Reply-To: <1382875566.3143.15.camel@fdeutsch-laptop.local> References: <1382377541.2828.45.camel@fdeutsch-laptop.local> <1511837625.14165477.1382871486005.JavaMail.root@redhat.com> <1382875566.3143.15.camel@fdeutsch-laptop.local> Message-ID: <20131028003843.GA12280@redhat.com> On Sun, Oct 27, 2013 at 01:06:06PM +0100, Fabian Deutsch wrote: > Am Sonntag, den 27.10.2013, 06:58 -0400 schrieb Moti Asayag: > > > > ----- Original Message ----- > > > From: "Fabian Deutsch" > > > To: "arch" , "node-devel" > > > Sent: Monday, October 21, 2013 8:45:41 PM > > > Subject: [node-devel] Needed: Node and Engine cooperation > > > > > > Hey, > > > > > > with the extraction of the oVirt Engine / VDSM specific bits from Node > > > in it's 3.0 release, oVirt Node became unaware of when it is being > > > managed. > > > Pre-3.0 Node (it's TUI) had specific knowledge about what configuration > > > files existed when it was registered to Engine. This is not the case in > > > Node 3.0 anymore. And this leads to problems. E.g. a user removing > > > Engines network layout. > > > > > > A new way is needed to pass informations between the management instance > > > and Node's core. This informations are needed e.g. to prevent the user > > > from accidentally destroying Engines network layout on a Node. > > > > How is it different from an admin connecting to non ovirt-node host and manually > > dis-configure its network ? > > You are right that there is not really a difference between those both > scenarios. > If vdsm can cope with this then this shouldn't be a problem. > My assumption was that vdsm had problems when the network configuration > got changed on a different way than through vdsm. > If vdsm is fine with this - the network configuration changed by the > user - then this is fine and we don't have a problem. Vdsm is not "fine" with arbitrary changes to network configuration done under its feet. If you're configuring an oVirt node, we strongly recommend doing it via Engine. Anything else is likely to break something or to be overridden by Engine. Let alone trigger evil races within initscripts or Vdsm. For plain (non ovirt-node) hosts, we trust admins to know what they are doing. The premise of ovirt-node is a bit different: it's all about hard-to-tweak-and-break. As much as I personally hate when my admin hands are tied by an application, I think it is sensible for the TUI to report which Engine controls it, and to lock the network configuration page when the node is remote-controlled. However, the TUI should allow explicit unlocking of the "remote-controlled". > > > I'm not sure we need to prevent from the administrator to perform any manual > > changes on the host. Perhaps the TUI could reflect the networks name by querying > > vdsm/libvirt in the same sense as the engine does so the user will be aware which > > interfaces carry logical networks. > > The problem here is that the TUI is not aware of vdsm. That's why I > suggest that VDSM is publishing these informations through e.g. the > mechanism which is mentioned in [0] or also maybe through > http://wiki.ovirt.org/Features/Node/FeaturePublishing > > Greetings > fabian > > > > > > > I've opened a bug [0] to suggest a way of sharing this kind of > > > informations. > > > > > > The idea is that Node and the management instance - Engine - share a set > > > of common configuration keys in /etc/default/ovirt to pass the relevant > > > bit's to Node. > > > For now I thought about this three keys: > > > > > > > > > OVIRT_MANAGED_BY= > > > This key is used to (a) signal the Node is being managed and (b) > > > signaling who is managing this node. "vendor" is less interesting than the managing app, and the location of its access point. > > > > > > OVIRT_MANAGED_IFNAMES=[,,...] > > > This key is used to specify a number (comma separated list) of ifnames > > > which are managed and for which the TUI shall display some information > > > (IP, ...). > > > This can also be used by the TUI to decide to not offer NIC > > > configuration to the user. I do not see the benefit of this. All (non-wifi) nics of a host are reported by Vdsm to Engine and thus manage-able by the latter. > > > > > > OVIRT_MANAGED_LOCKED_PAGES=[,,...] > > > (Future) A list of pages which shall be locked e.g. because the > > > management instance is configuring the aspect (e.g. networking or > > > logging). > > > > > > > > > The third one (OVIRT_MANAGED_LOCKED_PAGES) needs a tighter integration > > > and might be relevant in the future, but the first two should really be > > > implemented quickly for the reasons given above. .. but that's the only thing we need... > > > > > > It is quit elate in the development process but probably worth to think > > > about getting this into 3.3.1, to prevent all sorts of (accidentally) > > > user-driven collisions between Node and Engine. Please do not delay the 3.3.1 beta for this. I prefer a release note: "do not attempt to configure node networking when registered to Engine, unless you really know what your are doing." From phresus at gmail.com Mon Oct 28 16:19:33 2013 From: phresus at gmail.com (Ryan Barry) Date: Mon, 28 Oct 2013 09:19:33 -0700 Subject: [node-devel] Needed: Node and Engine cooperation In-Reply-To: References: Message-ID: <526E8E95.8020907@gmail.com> On 10/28/2013 09:00 AM, arch-request at ovirt.org wrote: > I do not see the benefit of this. All (non-wifi) nics of a host are > reported by Vdsm to Engine and thus manage-able by the latter. Part of the argument for this is for a non-VDSM node. We're already shipping base node images, and any uptake (whether internal or external) for another use may benefit. Not that we're currently doing it, but Neutron/Quantum explicitly recommend having an unconfigured NIC for tenant traffic, and a hypothetical Node+Nova+Neutron image would see a large benefit from a configuration key which allowed some NICs to be configured while leaving others (for GRE/VLAN tenant traffic) locked. From alonbl at redhat.com Mon Oct 28 16:24:17 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 28 Oct 2013 12:24:17 -0400 (EDT) Subject: [node-devel] Needed: Node and Engine cooperation In-Reply-To: <526E8E95.8020907@gmail.com> References: <526E8E95.8020907@gmail.com> Message-ID: <2005465960.9245016.1382977457745.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ryan Barry" > To: arch at ovirt.org > Sent: Monday, October 28, 2013 6:19:33 PM > Subject: Re: [node-devel] Needed: Node and Engine cooperation > > > On 10/28/2013 09:00 AM, arch-request at ovirt.org wrote: > > I do not see the benefit of this. All (non-wifi) nics of a host are > > reported by Vdsm to Engine and thus manage-able by the latter. > Part of the argument for this is for a non-VDSM node. We're already > shipping base node images, and any uptake (whether internal or external) > for another use may benefit. Not that we're currently doing it, but > Neutron/Quantum explicitly recommend having an unconfigured NIC for > tenant traffic, and a hypothetical Node+Nova+Neutron image would see a > large benefit from a configuration key which allowed some NICs to be > configured while leaving others (for GRE/VLAN tenant traffic) locked. This is up to the administrator to decide / change. We cannot (and I think we should not) protect administrator from him-self. Once computer had been added to manager, it should be managed by manager, if administrator finds a reason to locally manage a centralized remote managed host, it is probably because there is some kind of problem. Regards, Alon From iheim at redhat.com Tue Oct 29 17:46:57 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 29 Oct 2013 19:46:57 +0200 Subject: oVirt 3.4 planning Message-ID: <526FF491.5000204@redhat.com> To try and improve 3.4 planning over the wiki approach in 3.3, I've placed the items i collected on users list last time into a google doc[1] now, the main thing each item needs is a requirements owner, devel owner and a testing owner (well, devel owner is really needed to make it happen, but all are important). then we need an oVirt BZ for each, and for some a feature page. I also added columns indicating if the item will require an API design review and a GUI design review. this list is just the start of course for items from it to get ownership. i expect more items will be added as well, as long as they have owners, etc. the doc is public read-only, please request read-write access to be able to edit it. feel free to ask questions, etc. Thanks, Itamar [1] http://bit.ly/17qBn6F From danken at redhat.com Thu Oct 31 09:36:53 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 31 Oct 2013 09:36:53 +0000 Subject: oVirt 3.4 planning In-Reply-To: <526FF491.5000204@redhat.com> References: <526FF491.5000204@redhat.com> Message-ID: <20131031093653.GA29881@redhat.com> On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: > To try and improve 3.4 planning over the wiki approach in 3.3, I've > placed the items i collected on users list last time into a google > doc[1] > > now, the main thing each item needs is a requirements owner, devel > owner and a testing owner (well, devel owner is really needed to > make it happen, but all are important). > > then we need an oVirt BZ for each, and for some a feature page. > > I also added columns indicating if the item will require an API > design review and a GUI design review. > > this list is just the start of course for items from it to get > ownership. i expect more items will be added as well, as long as > they have owners, etc. > > the doc is public read-only, please request read-write access to be > able to edit it. > > feel free to ask questions, etc. I'd love to add vdsm-reg phase-out to the list. It's a code-only change, but it requires tracking. Bug 994451 - [vdsm-reg] retire vdsm-reg Another one on my wishlist is per-network custom properties and hooks. Having something like that would enable users do all kind of funky network configurations that are currently unsupported by oVirt. Dan. From iheim at redhat.com Thu Oct 31 10:10:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 31 Oct 2013 12:10:20 +0200 Subject: oVirt 3.4 planning In-Reply-To: <20131031093653.GA29881@redhat.com> References: <526FF491.5000204@redhat.com> <20131031093653.GA29881@redhat.com> Message-ID: <52722C8C.40505@redhat.com> On 10/31/2013 11:36 AM, Dan Kenigsberg wrote: > On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: >> To try and improve 3.4 planning over the wiki approach in 3.3, I've >> placed the items i collected on users list last time into a google >> doc[1] >> >> now, the main thing each item needs is a requirements owner, devel >> owner and a testing owner (well, devel owner is really needed to >> make it happen, but all are important). >> >> then we need an oVirt BZ for each, and for some a feature page. >> >> I also added columns indicating if the item will require an API >> design review and a GUI design review. >> >> this list is just the start of course for items from it to get >> ownership. i expect more items will be added as well, as long as >> they have owners, etc. >> >> the doc is public read-only, please request read-write access to be >> able to edit it. >> >> feel free to ask questions, etc. > > I'd love to add vdsm-reg phase-out to the list. It's a code-only change, > but it requires tracking. > > Bug 994451 - [vdsm-reg] retire vdsm-reg I think its clear its deprecated, but need to remain until we move to "4.0" when a lot of other things to be deprecated are ready. > > Another one on my wishlist is per-network custom properties and hooks. > Having something like that would enable users do all kind of funky > network configurations that are currently unsupported by oVirt. well, please add to the google doc... > > Dan. > From danken at redhat.com Thu Oct 31 10:40:37 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 31 Oct 2013 10:40:37 +0000 Subject: oVirt 3.4 planning In-Reply-To: <52722C8C.40505@redhat.com> References: <526FF491.5000204@redhat.com> <20131031093653.GA29881@redhat.com> <52722C8C.40505@redhat.com> Message-ID: <20131031104036.GB3737@redhat.com> On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote: > On 10/31/2013 11:36 AM, Dan Kenigsberg wrote: > >On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: > >>To try and improve 3.4 planning over the wiki approach in 3.3, I've > >>placed the items i collected on users list last time into a google > >>doc[1] > >> > >>now, the main thing each item needs is a requirements owner, devel > >>owner and a testing owner (well, devel owner is really needed to > >>make it happen, but all are important). > >> > >>then we need an oVirt BZ for each, and for some a feature page. > >> > >>I also added columns indicating if the item will require an API > >>design review and a GUI design review. > >> > >>this list is just the start of course for items from it to get > >>ownership. i expect more items will be added as well, as long as > >>they have owners, etc. > >> > >>the doc is public read-only, please request read-write access to be > >>able to edit it. > >> > >>feel free to ask questions, etc. > > > >I'd love to add vdsm-reg phase-out to the list. It's a code-only change, > >but it requires tracking. > > > > Bug 994451 - [vdsm-reg] retire vdsm-reg > > I think its clear its deprecated, but need to remain until we move > to "4.0" when a lot of other things to be deprecated are ready. It's still in use today, when a node registers itself to ovirt-engine-3.3. We should replace it with a much simpler http call, and keep vdsm-reg optional for the (very) few users who would like to register an ovirt-node-3.4 to an engine <= 3.1. > > > > >Another one on my wishlist is per-network custom properties and hooks. > >Having something like that would enable users do all kind of funky > >network configurations that are currently unsupported by oVirt. > > well, please add to the google doc... Would you grant me (actually danken at gmail) write access? Or better move the list the wiki... Editing tables in wiki syntax is no fun, but maintaining a private acl on this google doc sounds like hell to me. From fabiand at redhat.com Thu Oct 31 10:42:49 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 31 Oct 2013 11:42:49 +0100 Subject: oVirt 3.4 planning In-Reply-To: <20131031104036.GB3737@redhat.com> References: <526FF491.5000204@redhat.com> <20131031093653.GA29881@redhat.com> <52722C8C.40505@redhat.com> <20131031104036.GB3737@redhat.com> Message-ID: <1383216169.25583.3.camel@fdeutsch-laptop.local> Am Donnerstag, den 31.10.2013, 10:40 +0000 schrieb Dan Kenigsberg: > On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote: > > On 10/31/2013 11:36 AM, Dan Kenigsberg wrote: > > >On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: > > >>To try and improve 3.4 planning over the wiki approach in 3.3, I've > > >>placed the items i collected on users list last time into a google > > >>doc[1] > > >> > > >>now, the main thing each item needs is a requirements owner, devel > > >>owner and a testing owner (well, devel owner is really needed to > > >>make it happen, but all are important). > > >> > > >>then we need an oVirt BZ for each, and for some a feature page. > > >> > > >>I also added columns indicating if the item will require an API > > >>design review and a GUI design review. > > >> > > >>this list is just the start of course for items from it to get > > >>ownership. i expect more items will be added as well, as long as > > >>they have owners, etc. > > >> > > >>the doc is public read-only, please request read-write access to be > > >>able to edit it. > > >> > > >>feel free to ask questions, etc. > > > > > >I'd love to add vdsm-reg phase-out to the list. It's a code-only change, > > >but it requires tracking. > > > > > > Bug 994451 - [vdsm-reg] retire vdsm-reg > > > > I think its clear its deprecated, but need to remain until we move > > to "4.0" when a lot of other things to be deprecated are ready. > > It's still in use today, when a node registers itself to > ovirt-engine-3.3. We should replace it with a much simpler http call, > and keep vdsm-reg optional for the (very) few users who would like to > register an ovirt-node-3.4 to an engine <= 3.1. There is already going some light discussion going on about this simple http call here: https://bugzilla.redhat.com/show_bug.cgi?id=875088 - fabian > > > > > > > >Another one on my wishlist is per-network custom properties and hooks. > > >Having something like that would enable users do all kind of funky > > >network configurations that are currently unsupported by oVirt. > > > > well, please add to the google doc... > > Would you grant me (actually danken at gmail) write access? Or better > move the list the wiki... Editing tables in wiki syntax is no fun, but > maintaining a private acl on this google doc sounds like hell to me. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From danken at redhat.com Thu Oct 31 12:26:09 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 31 Oct 2013 12:26:09 +0000 Subject: oVirt 3.4 planning In-Reply-To: <1383216169.25583.3.camel@fdeutsch-laptop.local> References: <526FF491.5000204@redhat.com> <20131031093653.GA29881@redhat.com> <52722C8C.40505@redhat.com> <20131031104036.GB3737@redhat.com> <1383216169.25583.3.camel@fdeutsch-laptop.local> Message-ID: <20131031122609.GA10370@redhat.com> On Thu, Oct 31, 2013 at 11:42:49AM +0100, Fabian Deutsch wrote: > Am Donnerstag, den 31.10.2013, 10:40 +0000 schrieb Dan Kenigsberg: > > On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote: > > > On 10/31/2013 11:36 AM, Dan Kenigsberg wrote: > > > >On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: > > > >>To try and improve 3.4 planning over the wiki approach in 3.3, I've > > > >>placed the items i collected on users list last time into a google > > > >>doc[1] > > > >> > > > >>now, the main thing each item needs is a requirements owner, devel > > > >>owner and a testing owner (well, devel owner is really needed to > > > >>make it happen, but all are important). > > > >> > > > >>then we need an oVirt BZ for each, and for some a feature page. > > > >> > > > >>I also added columns indicating if the item will require an API > > > >>design review and a GUI design review. > > > >> > > > >>this list is just the start of course for items from it to get > > > >>ownership. i expect more items will be added as well, as long as > > > >>they have owners, etc. > > > >> > > > >>the doc is public read-only, please request read-write access to be > > > >>able to edit it. > > > >> > > > >>feel free to ask questions, etc. > > > > > > > >I'd love to add vdsm-reg phase-out to the list. It's a code-only change, > > > >but it requires tracking. > > > > > > > > Bug 994451 - [vdsm-reg] retire vdsm-reg > > > > > > I think its clear its deprecated, but need to remain until we move > > > to "4.0" when a lot of other things to be deprecated are ready. > > > > It's still in use today, when a node registers itself to > > ovirt-engine-3.3. We should replace it with a much simpler http call, > > and keep vdsm-reg optional for the (very) few users who would like to > > register an ovirt-node-3.4 to an engine <= 3.1. > > There is already going some light discussion going on about this simple > http call here: https://bugzilla.redhat.com/show_bug.cgi?id=875088 Good! I am asking Bug 875088 - ovirt-node-registration - a generic node registration to be declated as a 3.4 feature. From iheim at redhat.com Thu Oct 31 12:37:26 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 31 Oct 2013 14:37:26 +0200 Subject: oVirt 3.4 planning In-Reply-To: <20131031104036.GB3737@redhat.com> References: <526FF491.5000204@redhat.com> <20131031093653.GA29881@redhat.com> <52722C8C.40505@redhat.com> <20131031104036.GB3737@redhat.com> Message-ID: <52724F06.9090301@redhat.com> On 10/31/2013 12:40 PM, Dan Kenigsberg wrote: > On Thu, Oct 31, 2013 at 12:10:20PM +0200, Itamar Heim wrote: >> On 10/31/2013 11:36 AM, Dan Kenigsberg wrote: >>> On Tue, Oct 29, 2013 at 07:46:57PM +0200, Itamar Heim wrote: >>>> To try and improve 3.4 planning over the wiki approach in 3.3, I've >>>> placed the items i collected on users list last time into a google >>>> doc[1] >>>> >>>> now, the main thing each item needs is a requirements owner, devel >>>> owner and a testing owner (well, devel owner is really needed to >>>> make it happen, but all are important). >>>> >>>> then we need an oVirt BZ for each, and for some a feature page. >>>> >>>> I also added columns indicating if the item will require an API >>>> design review and a GUI design review. >>>> >>>> this list is just the start of course for items from it to get >>>> ownership. i expect more items will be added as well, as long as >>>> they have owners, etc. >>>> >>>> the doc is public read-only, please request read-write access to be >>>> able to edit it. >>>> >>>> feel free to ask questions, etc. >>> >>> I'd love to add vdsm-reg phase-out to the list. It's a code-only change, >>> but it requires tracking. >>> >>> Bug 994451 - [vdsm-reg] retire vdsm-reg >> >> I think its clear its deprecated, but need to remain until we move >> to "4.0" when a lot of other things to be deprecated are ready. > > It's still in use today, when a node registers itself to > ovirt-engine-3.3. We should replace it with a much simpler http call, > and keep vdsm-reg optional for the (very) few users who would like to > register an ovirt-node-3.4 to an engine <= 3.1. > >> >>> >>> Another one on my wishlist is per-network custom properties and hooks. >>> Having something like that would enable users do all kind of funky >>> network configurations that are currently unsupported by oVirt. >> >> well, please add to the google doc... > > Would you grant me (actually danken at gmail) write access? Or better > move the list the wiki... Editing tables in wiki syntax is no fun, but > maintaining a private acl on this google doc sounds like hell to me. > just ask via the google doc... lets see how it works, its for sure much easier to work with a real spreadsheet... From dneary at redhat.com Thu Oct 31 15:52:59 2013 From: dneary at redhat.com (Dave Neary) Date: Thu, 31 Oct 2013 16:52:59 +0100 Subject: [Users] oVirt 3.4 planning In-Reply-To: <526FF491.5000204@redhat.com> References: <526FF491.5000204@redhat.com> Message-ID: <52727CDB.9070705@redhat.com> Hi, Just to be clear: if you requested a feature last month, this is a great chance to help make it happen. To do so: * Ask for write access to the document below and add yourself as the "requirements owner" * Create a Feature page for the feature in the wiki, describing the user-facing experience you expect. Inputs, outputs, behaviour - all high level and user facing, nothing to do with implementation * Create a bug in Bugzilla (if there is not one already) to link both in the feature page and the summary doc below Another way to help is: * Add yourself as "test owner" for a feature - you are committing to putting the feature through its paces in a nightly build, when the coding is done. None of the features in the list are promised for 3.4 - it's a short development cycle, and I will be encouraging us to get to feature freeze as soon as reasonably possible - and the only way to guarantee a feature for inclusion is to sign up as the code owner, and agree to develop the feature yourself, but features with a good Feature page are *much* more likely to be implemented than those without. Thanks! Dave. On 10/29/2013 06:46 PM, Itamar Heim wrote: > now, the main thing each item needs is a requirements owner, devel owner > and a testing owner (well, devel owner is really needed to make it > happen, but all are important). > > then we need an oVirt BZ for each, and for some a feature page. > the doc is public read-only, please request read-write access to be able > to edit it. > [1] http://bit.ly/17qBn6F-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From alonbl at redhat.com Thu Oct 31 22:56:29 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 31 Oct 2013 18:56:29 -0400 (EDT) Subject: [ATN] ovirt-engine URIs rework In-Reply-To: <1681337895.11390844.1383259771041.JavaMail.root@redhat.com> Message-ID: <543755994.11391455.1383260189824.JavaMail.root@redhat.com> Hello, Please be aware that the following[1] was merged. Many thanks to Alexander Wels and Vojtech Szocs. --- MISSION Advanced farther into well behaved web application, install as much as we can into /ovirt-engine URI name space, removing / abuse. Synchronize between jboss and apache URI layouts so that development setup will be as similar as possible to production. NEW LAYOUT -+- / (root.war) Redirect: ovirt-engine | +--- api/ (api.war) | +-+- ovirt-engine/ (welcome.war) [NEW] | | | +--- docs/ (docs.war) [NEW] | | | +-+- services(services.war) [NEW] | | | | | +-+- attachment/ | | | | | +-+- files/ | | | | | +--- get-session-user | | | | | +--- health | | | | | +--- host-register | | | | | +--- pki-resource | | | | | +--- reports-redirect | | | +--- userportal/ (userportal.war) | | | +--- webadmin/ (webadmin.war) | +-+- OvirtEngineWeb/ | | | +--- HealthStatus.aspx Forward: ovirt-engine/services/health | | | +--- HealthStatus/* Forward: ovirt-engine/services/health | | | +--- VdsAutoRegistration.aspx Forward: ovirt-engine/services/host-register | | | +--- register Forward: ovirt-engine/services/host-register | +-+- RHEVManagerWeb/ | | | +--- VdsAutoRegistration.aspx Forward: ovirt-engine/services/host-register | +--- ca.crt Forward: ovirt-engine/serivces/pki-resource | +--- engine.ssh.key.txt Forward: ovirt-engine/serivces/pki-resource | +--- rhevm.ssh.key.txt Forward: ovirt-engine/serivces/pki-resource LAYOUT NOTES HealthStatus servlet is used by python using urllib2 which supports redirect, it does not accept extra path, so redirect into servlet at services is safe, but forward was installed for now. Registration uses python httplib which does not support redirect, so these uris are forwarded into servlets at services. /ValidateSession is gone as reports can be modified to support the new servlet name at /services/get-session-user. GWT applications have human usable URIs, no duplication no object names. [1] http://gerrit.ovirt.org/#/c/20473/