Re: [vdsm] vdsm hosts clock sync
- Original Message - From: Shahar Havivi shah...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 2:54:07 PM Subject: Re: [vdsm] vdsm hosts clock sync On 06.04.15 07:50, Alon Bar-Lev wrote: - Original Message - From: Shahar Havivi shah...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 2:44:06 PM Subject: [vdsm] vdsm hosts clock sync Hi, I want to add a new feature that reports migration actual downtime (the time that the VM was inaccessible to the user). Libvirt reports that information but the vdsm hosts need to be in sync by clock time. I can measure the ping for NTP server an report back to the user if the ping is too long (more then ~100ms or so) - a way to do that is via ntpstat shell command. The NTP delay can be report back via vdsStats and can be performed every few hours or so. Anyone knows of a better way that we can sync between hosts? I am unsure how a ping to clock source is helping, can you please explain more? In this case I can only report back to the user that its hosts clock is delayed and need to be set... If you assume clocks are synced why anything more is needed? Why do I assume that? Or would you like to have a solution in which you do not require clock sync? I do need the clock to be in sync - if not libvirts actual downtime migration will be not accurate. you do not need clock to sync, you need to know the delta between hosts. but if you assume clock are in sync so what is the actual question? Thank you, Shahar Havivi. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm hosts clock sync
- Original Message - From: Shahar Havivi shah...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 2:44:06 PM Subject: [vdsm] vdsm hosts clock sync Hi, I want to add a new feature that reports migration actual downtime (the time that the VM was inaccessible to the user). Libvirt reports that information but the vdsm hosts need to be in sync by clock time. I can measure the ping for NTP server an report back to the user if the ping is too long (more then ~100ms or so) - a way to do that is via ntpstat shell command. The NTP delay can be report back via vdsStats and can be performed every few hours or so. Anyone knows of a better way that we can sync between hosts? I am unsure how a ping to clock source is helping, can you please explain more? If you assume clocks are synced why anything more is needed? Or would you like to have a solution in which you do not require clock sync? Thank you, Shahar Havivi. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm hosts clock sync
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Shahar Havivi shah...@redhat.com, Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 4:31:44 PM Subject: Re: [vdsm] vdsm hosts clock sync On 6 Apr 2015, at 14:05, Shahar Havivi wrote: On 06.04.15 08:00, Alon Bar-Lev wrote: - Original Message - From: Shahar Havivi shah...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 2:54:07 PM Subject: Re: [vdsm] vdsm hosts clock sync On 06.04.15 07:50, Alon Bar-Lev wrote: - Original Message - From: Shahar Havivi shah...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, April 6, 2015 2:44:06 PM Subject: [vdsm] vdsm hosts clock sync Hi, I want to add a new feature that reports migration actual downtime (the time that the VM was inaccessible to the user). Libvirt reports that information but the vdsm hosts need to be in sync by clock time. I can measure the ping for NTP server an report back to the user if the ping is too long (more then ~100ms or so) - a way to do that is via ntpstat shell command. The NTP delay can be report back via vdsStats and can be performed every few hours or so. Anyone knows of a better way that we can sync between hosts? I am unsure how a ping to clock source is helping, can you please explain more? In this case I can only report back to the user that its hosts clock is delayed and need to be set… I had in mind that hosts are synchronized by NTP and we report the difference between local time and the reference (NTP) time, i.e. what ntpstat returns This way we don't need to ping around or compare directly all the hosts, but we can rely on the same source and individual hosts's awareness of accuracy If you assume clocks are synced why anything more is needed? Why do I assume that? the feature requires those 2 hosts to have same clock, not necessarily the correct one. But I believe having all hosts sync to the actual time is beneficial on its own Or would you like to have a solution in which you do not require clock sync? I do need the clock to be in sync - if not libvirts actual downtime migration will be not accurate. you do not need clock to sync, you need to know the delta between hosts. the libvirt API uses the delta internally so we can't use only that. Also I think it is easier to have clock synced by a tool designated for that but if you assume clock are in sync so what is the actual question? As I understand from your answer is by having configured ntp the hosts clock are in sync. we need to report that they are sync and how off the actual local clock is once again, you have the solution so why ask the question? you assume ntpd - please make sure it is actually configured. Thanks, michal Thank you, Shahar Havivi. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:37:14 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org Sent: Thursday, October 10, 2013 5:24:40 PM Subject: Re: Recent changes in vdsmd startup On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: Hey Everybody, FYI, Recently we merged a fix that changes the way vdsmd starts. Before that service vdsmd start command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. So now when you perform vdsmd start after clear installation you will see: ~$ sudo service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm: not running [FAILED] vdsm: Running run_final_hooks vdsm stop [ OK ] supervdsm start[ OK ] vdsm: Running run_init_hooks vdsm: Running gencerts hostname: Unknown host vdsm: Running check_libvirt_configure libvirt is not configured for vdsm yet Perform 'vdsm-tool libvirt-configure' before starting vdsmd vdsm: failed to execute check_libvirt_configure, error code 1 vdsm start [FAILED] This asks you to run vdsm-tool libvirt-configure After running it you should see: ~$ sudo vdsm-tool libvirt-configure Stopping libvirtd daemon: [ OK ] libvirt is not configured for vdsm yet Reconfiguration of libvirt is done. To start working with the new configuration, execute: 'vdsm-tool libvirt-configure-services-restart' This will manage restarting of the following services: libvirtd, supervdsmd After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. Over systemd the errors\output can be watched in /var/log/messages Thanks, Yaniv Bronhaim. ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. The prints I copied above are relevant only if user tries to install and start vdsmd manually great. so how does backward compatibility work? i have a 3.2 engine, and i deploy latest vdsm due to some bug fixes. (i.e., i didn't get new host-deploy) This was already supported in last iteration. The init.d and systemd script support reconfigure verb that is executed ever since vdsm-bootstrap, these are kept for backward compatibility. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:39:35 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:37:14 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org Sent: Thursday, October 10, 2013 5:24:40 PM Subject: Re: Recent changes in vdsmd startup On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: Hey Everybody, FYI, Recently we merged a fix that changes the way vdsmd starts. Before that service vdsmd start command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. So now when you perform vdsmd start after clear installation you will see: ~$ sudo service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm: not running [FAILED] vdsm: Running run_final_hooks vdsm stop [ OK ] supervdsm start[ OK ] vdsm: Running run_init_hooks vdsm: Running gencerts hostname: Unknown host vdsm: Running check_libvirt_configure libvirt is not configured for vdsm yet Perform 'vdsm-tool libvirt-configure' before starting vdsmd vdsm: failed to execute check_libvirt_configure, error code 1 vdsm start [FAILED] This asks you to run vdsm-tool libvirt-configure After running it you should see: ~$ sudo vdsm-tool libvirt-configure Stopping libvirtd daemon: [ OK ] libvirt is not configured for vdsm yet Reconfiguration of libvirt is done. To start working with the new configuration, execute: 'vdsm-tool libvirt-configure-services-restart' This will manage restarting of the following services: libvirtd, supervdsmd After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. Over systemd the errors\output can be watched in /var/log/messages Thanks, Yaniv Bronhaim. ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. The prints I copied above are relevant only if user tries to install and start vdsmd manually great. so how does backward compatibility work? i have a 3.2 engine, and i deploy latest vdsm due to some bug fixes. (i.e., i didn't get new host-deploy) This was already supported in last iteration. The init.d and systemd script support reconfigure verb that is executed ever since vdsm-bootstrap, these are kept for backward compatibility. so what happens to 3.2 engine with this new vdsm, without this patch? http://gerrit.ovirt.org/20102 this patch is just adjustment to whatever yaniv plans now. up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above. now host-deploy will be adjusted to call a single verb to configure whatever need to be configured by vdsm. waiting for interface of vdsm-tool to stabilize before attempting to fix. 3.2, 3.1, 3.0 uses the old method of reconfigure, it does not use vdsm tool. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:43 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:39:35 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:37:14 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org Sent: Thursday, October 10, 2013 5:24:40 PM Subject: Re: Recent changes in vdsmd startup On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: Hey Everybody, FYI, Recently we merged a fix that changes the way vdsmd starts. Before that service vdsmd start command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. So now when you perform vdsmd start after clear installation you will see: ~$ sudo service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm: not running [FAILED] vdsm: Running run_final_hooks vdsm stop [ OK ] supervdsm start[ OK ] vdsm: Running run_init_hooks vdsm: Running gencerts hostname: Unknown host vdsm: Running check_libvirt_configure libvirt is not configured for vdsm yet Perform 'vdsm-tool libvirt-configure' before starting vdsmd vdsm: failed to execute check_libvirt_configure, error code 1 vdsm start [FAILED] This asks you to run vdsm-tool libvirt-configure After running it you should see: ~$ sudo vdsm-tool libvirt-configure Stopping libvirtd daemon: [ OK ] libvirt is not configured for vdsm yet Reconfiguration of libvirt is done. To start working with the new configuration, execute: 'vdsm-tool libvirt-configure-services-restart' This will manage restarting of the following services: libvirtd, supervdsmd After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. Over systemd the errors\output can be watched in /var/log/messages Thanks, Yaniv Bronhaim. ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. The prints I copied above are relevant only if user tries to install and start vdsmd manually great. so how does backward compatibility work? i have a 3.2 engine, and i deploy latest vdsm due to some bug fixes. (i.e., i didn't get new host-deploy) This was already supported in last iteration. The init.d and systemd script support reconfigure verb that is executed ever since vdsm-bootstrap, these are kept for backward compatibility. so what happens to 3.2 engine with this new vdsm, without this patch? http://gerrit.ovirt.org/20102 this patch is just adjustment to whatever yaniv plans now. up until now host-deploy tried to execute vdsm-tool libvirt-configure and if fails it tries the old way as I described above. now host-deploy will be adjusted
Re: [vdsm] Recent changes in vdsmd startup
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 8:33:39 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:47 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:43 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:39:35 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:37:14 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org Sent: Thursday, October 10, 2013 5:24:40 PM Subject: Re: Recent changes in vdsmd startup On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: Hey Everybody, FYI, Recently we merged a fix that changes the way vdsmd starts. Before that service vdsmd start command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. So now when you perform vdsmd start after clear installation you will see: ~$ sudo service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm: not running [FAILED] vdsm: Running run_final_hooks vdsm stop [ OK ] supervdsm start[ OK ] vdsm: Running run_init_hooks vdsm: Running gencerts hostname: Unknown host vdsm: Running check_libvirt_configure libvirt is not configured for vdsm yet Perform 'vdsm-tool libvirt-configure' before starting vdsmd vdsm: failed to execute check_libvirt_configure, error code 1 vdsm start [FAILED] This asks you to run vdsm-tool libvirt-configure After running it you should see: ~$ sudo vdsm-tool libvirt-configure Stopping libvirtd daemon: [ OK ] libvirt is not configured for vdsm yet Reconfiguration of libvirt is done. To start working with the new configuration, execute: 'vdsm-tool libvirt-configure-services-restart' This will manage restarting of the following services: libvirtd, supervdsmd After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. Over systemd the errors\output can be watched in /var/log/messages Thanks, Yaniv Bronhaim. ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host Of course it shouldn't effect any of the deploy process. If using the host-deploy, the host-deploy process should take care of stopping, starting and other managing that can be required before starting vdsmd, and it is taking care of. The prints I copied above are relevant only if user tries to install and start vdsmd manually great. so how does backward compatibility work? i have a 3.2 engine, and i deploy latest vdsm due to some bug fixes. (i.e., i didn't get new host-deploy) This was already supported in last iteration. The init.d and systemd script support reconfigure verb that is executed ever since
Re: [vdsm] Keeping VDSM Compatible with Ubuntu
- Original Message - From: Itamar Heim ih...@redhat.com To: vdsm-devel@lists.fedorahosted.org, in...@ovirt.org Sent: Saturday, September 28, 2013 10:24:00 PM Subject: Re: [vdsm] Keeping VDSM Compatible with Ubuntu On 09/27/2013 04:16 PM, Ewoud Kohl van Wijngaarden wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0800, Zhou Zheng Sheng wrote: Recently we merged some patches to make VDSM run on Ubuntu. We also have some packaging scripts in the debian/ sub-dir. You can either build .deb packages manually or find binary packages from VDSM PPA [1] on launchpad.net. Once you add that PPA, you can use apt-get to install VDSM and its dependencies. I'll setup a Jenkins on my laptop to test the master branch automatically by build and install VDSM on Ubuntu, then running unit and functional tests. I suggest when adding a new change, it's better to make sure it is covered by unit or functional tests. If you change the packaging code, for example adding new options to configure.ac, editing vdsm.spec.in, and changing VDSM daemon startup behavior, I am happy to be invited to review your patch. I'd also like to listen to your suggestions on this topic, thanks! I'd recommend getting in touch with infra to set up an ubuntu slave to ensure compatibility. We have our CI infra almost in a shape where we can easily add new slaves. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel +1 - if you can get to run some sanity tests per vdsm patch, you can prevent bad things from happening rather than chase things after they broke Usually I am for defining levels of support for each distribution (downstream), each level can contain more than one. 1st tier - always stable and up. 2nd tier - in tree support but synchronized periodically. 3rd tier - out of tree support endorsed by upstream. 4th tier - out of tree support. It is hard enough to properly support 1st tier. Requiring all developers to understand and not break packaging is hard enough, multiple packaging technologies is something that beyond valid requirement. The role of 2nd tier maintainer is periodically perform whatever is needed in order to sync up, and for larger changes work to integrate the requirement of other platforms into a solution. Of course from rc and beyond all 1st and 2nd tiers should be stable, so having automation to validate that is good at these stages. Regards, Alon Bar-Lev. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
- Original Message - From: Ayal Baron aba...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Tuesday, September 24, 2013 12:21:23 AM Subject: Re: [vdsm] stale gerrit patches - Original Message - - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:54:39 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z so how does it help us to have these patches, some without any comment from any reviewer. lets get them reviewed and decide one way or the other, rather than let them get old and stay forever Again... maintainer can close these if he likes. Owner can close these if he likes. right, but why? a patch without activity being abandoned might actually spur someone into motion (rebasing and resubmitting, prodding maintainers etc). I'm +1 for automatically abandoning old patches. I do not understand why maintainer should not have human interaction with its contributers. The problem is that maintainers avoid closing. And that there are people who submitted patches without CC anyone and gone. So a simple logic can be applied after we add metadata into tree: 1. If no maintainer is CCed on change, close that change within short cycle (can be even a week). 2. Maintainer to close patches that have no interest in. Maintainers can close patches that are no interest nor progress. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
- Original Message - From: Ayal Baron aba...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Tuesday, September 24, 2013 10:09:46 AM Subject: Re: [vdsm] stale gerrit patches - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Tuesday, September 24, 2013 9:20:55 AM Subject: Re: [vdsm] stale gerrit patches - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Tuesday, September 24, 2013 12:21:23 AM Subject: Re: [vdsm] stale gerrit patches - Original Message - - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:54:39 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z so how does it help us to have these patches, some without any comment from any reviewer. lets get them reviewed and decide one way or the other, rather than let them get old and stay forever Again... maintainer can close these if he likes. Owner can close these if he likes. right, but why? a patch without activity being abandoned might actually spur someone into motion (rebasing and resubmitting, prodding maintainers etc). I'm +1 for automatically abandoning old patches. I do not understand why maintainer should not have human interaction with its contributers. I do not understand the relation between the subject and the things you're saying. Right now these patches are stale and are rotting, abandoning them could actually spur those interactions into motion. You prefer machines to interact with contributers to kick them in motion. I believe
Re: [vdsm] stale gerrit patches
- Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. Maintainers can close patches that are no interest nor progress. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z Maintainers can close patches that are no interest nor progress. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Itamar Heim ih...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:52:56 PM Subject: Re: [vdsm] stale gerrit patches - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:ldap_independence,n,z Maintainers can close patches that are no interest nor progress. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:54:39 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:52 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: David Caro dcaro...@redhat.com, engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:50:35 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:49 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: David Caro dcaro...@redhat.com Cc: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 23, 2013 1:47:47 PM Subject: Re: [vdsm] stale gerrit patches On 09/23/2013 01:46 PM, David Caro wrote: On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. yep - warn after X days via email to just owner (or all subscribed to the patch), and close if no activity for X+14 days or something like that. This will be annoying. And there are patches that pending with good reason. pending for 60 days with zero activity on them (no comment, no rebase, nothing)? http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:independent_deployments,n,z so how does it help us to have these patches, some without any comment from any reviewer. lets get them reviewed and decide one way or the other, rather than let them get old and stay forever Again... maintainer can close these if he likes. Owner can close these if he likes. The problem is that maintainers avoid closing. And that there are people who submitted patches without CC anyone and gone. So a simple logic can be applied after we add metadata into tree: 1. If no maintainer is CCed on change, close that change within short cycle (can be even a week). 2. Maintainer to close patches that have no interest in. Maintainers can close patches that are no interest nor progress. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] qustion related to bootstrap
- Original Message - From: bigclouds bigclo...@163.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, September 9, 2013 12:18:47 PM Subject: [vdsm] qustion related to bootstrap hi,all in bootstrap.py. there is a function named '_addNetwork', what is meaning of its params(vdcName, vdcPort), and what is the purpose of waitRouteRestore? thanks This file is obsolete in 3.2, please refer to overt-host-deploy[1], more specifically bridge plugin[2]. The name and port are the engine's application, to allow detecting the interface to create management bridge on using the route to engine, and to allow detecting when management bridge is able to communicate to engine. In 3.3 this also obsoleted, as the management bridge is created post host-deploy using the engine. Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=blob;f=src/plugins/ovirt-host-deploy/vdsm/bridge.py;hb=HEAD ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] configNetwork issue
- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: vdsm-devel@lists.fedorahosted.org
Sent: Thursday, June 6, 2013 5:26:14 PM
Subject: [vdsm] configNetwork issue
Hi,
I'm trying to c reate a bridge adding as config bootproto ='dhcp'
but I've the following error:
import sys
sys.path.append('/usr/share/vdsm/')
import configNetwork
configNetwork.addNetwork(network='engine', nics=['em1'],
bootproto='dhcp')
TypeError: objectivizeNetwork() got multiple values for keyword argument
'bootproto'
seems like objectivizeNetwork already take boo tproto from **opts and fails.
Hi!
I think you should follow the ovirt-host-deploy bridge.py, and use addNetwork
utility:
['/usr/share/vdsm/addNetwork', 'ovirtmgmt', '', '', u'eth0', 'BOOTPROTO=dhcp',
'ONBOOT=yes', 'blockingdhcp=true']
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] What is the effect if I install vdsm-bootstrap
What do you mean? It should be used automatically by the ovirt-engine, nothing should be done manually. - Original Message - From: Mars gu gukaiov...@163.com To: Mars gu gukaiov...@163.com Cc: vdsm vdsm-devel@lists.fedorahosted.org Sent: Tuesday, May 14, 2013 1:42:22 PM Subject: Re: [vdsm] What is the effect if I install vdsm-bootstrap sorry , I will use ovirt-host-deploy instead of vdsm-bootstrap. typing error. At 2013-05-14 18:38:41,Mars gu gukaiov...@163.com wrote: Thanks Dan, My Engine version is 3.2.1. I will not use ovirt-host-deploy instead of vdsm-bootstrap. I doubt I must install ovirt-host-deploy-offline in hypervison side, is that right ? At 2013-05-14 17:19:15,Dan Kenigsberg dan...@redhat.com wrote: On Tue, May 14, 2013 at 04:48:00PM +0800, Mars gu wrote: hi, I find a rpm named vdsm-bootstrap. But I don't know how to use it. somebody can help me? vdsm-bootstrap is legacy code, that used to be installed on the ovirt-egine host, and used by Engine when a new host is added to the data center. However, with the advent of otopi, vdsm-bootstrap has been replaced by ovirt-host-deploy, and should not be used by new setups at all. Do you have a special use case in mind? Which Engine version are you using? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Porting vdsmd.init.in and vdsm.spec.in to Ubuntu
Great work! Can you please split commit to smaller, based on subject? I see most can be submitted today upstream. Change to vdsm/storage/12-vdsm-lvm.rules: You should add the owner and group to configure.ac and rename the file to an .in suffix so that substitutes can happen. This can be merged today if defaults are the same. Change to configure.ac and relevant also to the above... You should add --with-user-qemu= to autoconf, with the default of qemu, same for group and any change between distributions, then you can go ahead and configure the package properly with built. Change to tests/functional/xmlrpcTests.py I do not know the code well, but it seems like you can ask for distribution name and perform the assignment accordingly. Change to tests/run_tests.sh.in requires root, so I don't think it is wise... better just to fail test if the configfs is not mounted, asking user to make sure it is. uninstall - I am not sure it is required at all. Why did you change the order of the udev rules? Change to vdsm/storage/multipath.py - please detect distribution at autoconf and handle right service. Change to vdsm/storage/protect/spmstop.sh can be submitted now. Can you please explain change to vdsm/utils.py? I leave our the change for vdsm/vdsmd.init.in, as it needs much work, but we can leave as last task, it requires more detection using autoconf, and call common script. Thank you, Alon - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, March 20, 2013 12:00:57 PM Subject: [vdsm] Porting vdsmd.init.in and vdsm.spec.in to Ubuntu Hi guys, You may notice recently I work on porting VDSM to Ubuntu. I managed to run VDSM functional tests with some hacks in the code, then I documented the hacks and try to create long term solution patches for them [1]. I'm a bit stuck on the two files, vdsmd.init.in and vdsm.spec.in. I made a lot of small modifications to vdsmd.init.in to make it work in Ubuntu. Firstly I try to do it in the GNU autotools way to add more macros to this file, and make it adapt to Ubuntu. Then I find this file is already somewhat complicated, adding more macros to configure.ac and this file would make it worse. So I created a separate init file for Ubuntu based on vdsmd.init.in, but I find the structure and most part of the new file is the same as the original one. Dan suggests me break the init file into small functions and put the functions in vdsm-tool. I think this job may take long time and delay the process of porting VDSM. You can have a look at my modifications to this file at [2]. I have another idea. I can create a vdsm-contrib sub-directory under the VDSM source directory. Then put a vdsm-contrib/ubuntu/vdsmd.init.in.patch file in it. When the user build VDSM in Ubuntu, he can firstly patch the vdsmd.init.in. In this way we avoid creating more complicated macros and re-use the existing code. We do not have to maintain vdsmd.init.in.patch. There is no promise on this file to be patched cleanly in the long term. For now I can write new upates for vdsm-contrib/ubuntu temporarily. Once Ubuntu accept VDSM, we have them maintain the init file. How does this plan sound like? As regarding to vdsm.spec.in, I find there are some shell scripts to be executed during/after the installation. When I'm on Ubuntu, I grab the scripts out of vdsm.spec and run them to make VDSM work. If I want to create .deb files, these scripts should be re-used. Otherwise the spec file for .deb contains duplicated content from spec file for .rpm. My idea is crab these script out of .spec.in and create standalone scripts like vdsm_postInstall.sh. Then we distribute these script in vdsm package and invoke them after installation. If I could successfully port these two files, it would be a big step closer to my final goal. Could anyone gives me some suggestions? Really thanks. [1] http://www.ovirt.org/VDSM_on_Ubuntu [2] https://github.com/edwardbadboy/vdsm-ubuntu/commit/0b23299f48c5a341b73f2bb2b3dfdb58e82f5459 -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshz...@linux.vnet.ibm.com Telephone: 86-10-82454397 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Porting vdsmd.init.in and vdsm.spec.in to Ubuntu
- Original Message - From: Ewoud Kohl van Wijngaarden ew...@kohlvanwijngaarden.nl To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, March 20, 2013 2:31:35 PM Subject: Re: [vdsm] Porting vdsmd.init.in and vdsm.spec.in to Ubuntu On Wed, Mar 20, 2013 at 06:00:57PM +0800, Zhou Zheng Sheng wrote: You can have a look at my modifications to this file at https://github.com/edwardbadboy/vdsm-ubuntu/commit/0b23299f48c5a341b73f2bb2b3dfdb58e82f5459 I know oVirt isn't using github to develop, but you could fork it from https://github.com/oVirt/vdsm so it's at least tracked. I don't think there is no difference between forking in github or cloning a repository, if changes are to be pushed eventually to gerrit. Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm networking changes proposal
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Wednesday, February 27, 2013 11:14:35 AM Subject: Re: vdsm networking changes proposal On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Tuesday, February 26, 2013 5:45:50 PM Subject: Re: vdsm networking changes proposal On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Monday, February 25, 2013 12:34:46 PM Subject: Re: vdsm networking changes proposal On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I agree with you - even though OOD is falling out of fashion in certain circles. If we develop software like dressing fashion, we end up with software working for a single season. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Just as we may decide to move away from standard linux bridge to ovs-based bridging, we may switch from bonding to teaming. I do not think that we should do it now, but make sure that the design accomodates this. So there should a separate provider for each object type, unless I am missing something. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs I do not think that such complex combinations are of real interest. The client should not (currently) be allowed to request them. Some say that the specific combination that is used by Vdsm to implement the network should be defined in a config file. I think that a python file is good enough for that, at least for now. I completely lost you, and how it got to do with python nor file. If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? If we register provider per object type we may allow easier reuse. Yes, this is the plan. However I do not think it is wise to support all conceivable combinations of provider/object. A fixed one, such as ovs for bridge and vlan, iproute2 for bond is good enough. The whole point of the abstraction/provider thing is to vdsm *NOT* be aware of the underline technologies. I would not like to see 'if ovs then' or any other similar one in vdsm code after we have this mechanism in place. Vdsm has to be aware of the underlying technologies, but this awareness has to be confined to two places: - the providers. - the thing that selects which provider should be used today. I don't understand the 2nd item... why is 'today' important? and what is 'thing'? Not that I say that a total generic sequence will require to work, but the ovs for bridge and vlan should be compatible with iproute for bond, while iproute for bridge and iproute for vlan and iproute for bond are compatible as well. Sure. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm networking changes proposal
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Wednesday, February 27, 2013 2:02:48 PM Subject: Re: vdsm networking changes proposal On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Wednesday, February 27, 2013 11:14:35 AM Subject: Re: vdsm networking changes proposal On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Tuesday, February 26, 2013 5:45:50 PM Subject: Re: vdsm networking changes proposal On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Monday, February 25, 2013 12:34:46 PM Subject: Re: vdsm networking changes proposal On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I agree with you - even though OOD is falling out of fashion in certain circles. If we develop software like dressing fashion, we end up with software working for a single season. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Just as we may decide to move away from standard linux bridge to ovs-based bridging, we may switch from bonding to teaming. I do not think that we should do it now, but make sure that the design accomodates this. So there should a separate provider for each object type, unless I am missing something. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs I do not think that such complex combinations are of real interest. The client should not (currently) be allowed to request them. Some say that the specific combination that is used by Vdsm to implement the network should be defined in a config file. I think that a python file is good enough for that, at least for now. I completely lost you, and how it got to do with python nor file. If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? If we register provider per object type we may allow easier reuse. Yes, this is the plan. However I do not think it is wise to support all conceivable combinations of provider/object. A fixed one, such as ovs for bridge and vlan, iproute2 for bond is good enough. The whole point of the abstraction/provider thing is to vdsm *NOT* be aware of the underline technologies. I would not like to see 'if ovs then' or any other similar one in vdsm code after we have
Re: [vdsm] vdsm networking changes proposal
- Original Message - From: David Jaša dj...@redhat.com To: vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Monday, February 18, 2013 11:23:21 AM Subject: Re: [vdsm] vdsm networking changes proposal Hi, Alon Bar-Lev píše v Ne 17. 02. 2013 v 15:57 -0500: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Team is a new implementation of bonding in Linux kernel IIRC. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. Isn't it better to separate the two goals and persuade qemu developers to implement TLS for migration connections? Sure :) But someone/something will need to configure it... :) For the open questions: 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. 3. I think that if we can avoid aliases it would be nice. 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management network setup from vdsm configuration instead of persisting it to the distribution width configuration. Regards, Alon Bar-Lev - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Friday, February 8, 2013 12:54:23 AM Subject: vdsm networking changes proposal Hi fellow oVirters! The network team and a few others have toyed in the past with several important changes like using open vSwitch, talking D-BUS to NM, making the network non-persistent, etc. It is with some of this changes in mind that we (special thanks go to Livnat Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for a new architecture for vdsm's networking part. This proposal is intended to make our software more adaptable to new components and use cases, eliminate distro dependancies as much as possible and improve the responsiveness and scalability of the networking operations. To do so, it proposes an object oriented representation of the different elements that come into play in our networking use cases. But enough of introduction, please go to the feature page that we have put together and help us with your feedback, questions proposals and extensions. http://www.ovirt.org/Feature/NetworkReloaded Best regards, Toni ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ vdsm-devel mailing list vdsm-devel
Re: [vdsm] vdsm networking changes proposal
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Monday, February 25, 2013 12:34:46 PM Subject: Re: vdsm networking changes proposal On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I agree with you - even though OOD is falling out of fashion in certain circles. If we develop software like dressing fashion, we end up with software working for a single season. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Just as we may decide to move away from standard linux bridge to ovs-based bridging, we may switch from bonding to teaming. I do not think that we should do it now, but make sure that the design accomodates this. So there should a separate provider for each object type, unless I am missing something. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs I do not think that such complex combinations are of real interest. The client should not (currently) be allowed to request them. Some say that the specific combination that is used by Vdsm to implement the network should be defined in a config file. I think that a python file is good enough for that, at least for now. I completely lost you, and how it got to do with python nor file. If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? If we register provider per object type we may allow easier reuse. This, however, does not imply that the implementation is in python (oh well...) nor if the implementation is single file or multiple file... ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. This is something completely different, as we say in Python. The nice thing about your idea, is that in the context of host network configuration we need nothing more than our current bridge-bond-nic. The sad thing about your idea, is that it would scale badly with the nubmer of virtual networks. If a new VM comes live and sends an ARP who-has broadcast message - which VMs should be bothered to attempt to decrypt it? This is easily filtered by a tag. Just like in MPLS. For the open questions: 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. 3. I think that if we can avoid aliases it would be nice. I wonder if everybody agrees that aliases are not needed. 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management
Re: [vdsm] vdsm networking changes proposal
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Tuesday, February 26, 2013 5:45:50 PM Subject: Re: vdsm networking changes proposal On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Monday, February 25, 2013 12:34:46 PM Subject: Re: vdsm networking changes proposal On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote: Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I agree with you - even though OOD is falling out of fashion in certain circles. If we develop software like dressing fashion, we end up with software working for a single season. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? Just as we may decide to move away from standard linux bridge to ovs-based bridging, we may switch from bonding to teaming. I do not think that we should do it now, but make sure that the design accomodates this. So there should a separate provider for each object type, unless I am missing something. bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs I do not think that such complex combinations are of real interest. The client should not (currently) be allowed to request them. Some say that the specific combination that is used by Vdsm to implement the network should be defined in a config file. I think that a python file is good enough for that, at least for now. I completely lost you, and how it got to do with python nor file. If we have implementation of iproute2 that does bridge, vlan, bond, but we like to use ovs for bridge and vlan, how can we reuse the iproute2 provider for the bond? If we register provider per object type we may allow easier reuse. Yes, this is the plan. However I do not think it is wise to support all conceivable combinations of provider/object. A fixed one, such as ovs for bridge and vlan, iproute2 for bond is good enough. The whole point of the abstraction/provider thing is to vdsm *NOT* be aware of the underline technologies. I would not like to see 'if ovs then' or any other similar one in vdsm code after we have this mechanism in place. Not that I say that a total generic sequence will require to work, but the ovs for bridge and vlan should be compatible with iproute for bond, while iproute for bridge and iproute for vlan and iproute for bond are compatible as well. This, however, does not imply that the implementation is in python (oh well...) nor if the implementation is single file or multiple file... ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. This is something completely different, as we say in Python. The nice thing about your idea, is that in the context of host network configuration we need nothing more than our current bridge-bond-nic. The sad thing about your idea, is that it would scale badly with the nubmer of virtual networks. If a new VM comes live and sends an ARP who-has broadcast message
Re: [vdsm] vdsm networking changes proposal
Hello Antoni, Great work! I am very excited we are going this route, it is first of many to allow us to be run on different distributions. I apologize I got to this so late. Notes for the model, I am unsure if someone already noted. I think that the abstraction should be more than entity and properties. For example: nic is a network interface bridge is a network interface and ports network interfaces bound is a network interface and slave network interfaces vlan is a network interface and vlan id network interface can have: - name - ip config - state - mtu this way it would be easier to share common code that handle pure interfaces. I don't quite understand the 'Team' configurator, are you suggesting a provider for each technology? bridge - iproute2 provider - ovs provider - ifcfg provider bond - iproute2 - team - ovs - ifcfg vlan - iproute2 - ovs - ifcfg So we can get a configuration of: bridge:iproute2 bond:team vlan:ovs ? I also would like us to explore a future alternative of the network configuration via crypto vpn directly from qemu to another qemu, the idea is to have a kerberos like key per layer3(or layer2) destination, while communication is encrypted at user space and sent to a flat network. The advantage of this is that we manage logical network and not physical network, while relaying on hardware to find the best route to destination. The question is how and if we can provide this via the suggestion abstraction. But maybe it is too soon to address this kind of future. For the open questions: 1. Yes, I think that mode should be non-persistence, persistence providers should emulate non-persistence operations by diff between what they have and the goal. 2. Once vdsm is installed, the mode it runs should be fixed. So the only question is what is the selected profile during host deployment. 3. I think that if we can avoid aliases it would be nice. 4. Keeping the least persistence information would be flexible. I would love to see a zero persistence mode available, for example if management interface is dhcp or manually configured. I am very fond of the iproute2 configuration, and don't mind if administrator configures the management interface manually. I think this can supersede the ifcfg quite easily in most cases. In these rare cases administrator use ovirt to modify the network interface we may consider delegating persistence to totally different model. But as far as I understand the problem is solely related to the management connectivity, so we can implement a simple bootstrap of non-persistence module to reconstruct the management network setup from vdsm configuration instead of persisting it to the distribution width configuration. Regards, Alon Bar-Lev - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: a...@ovirt.org, vdsm-de...@fedorahosted.org Sent: Friday, February 8, 2013 12:54:23 AM Subject: vdsm networking changes proposal Hi fellow oVirters! The network team and a few others have toyed in the past with several important changes like using open vSwitch, talking D-BUS to NM, making the network non-persistent, etc. It is with some of this changes in mind that we (special thanks go to Livnat Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for a new architecture for vdsm's networking part. This proposal is intended to make our software more adaptable to new components and use cases, eliminate distro dependancies as much as possible and improve the responsiveness and scalability of the networking operations. To do so, it proposes an object oriented representation of the different elements that come into play in our networking use cases. But enough of introduction, please go to the feature page that we have put together and help us with your feedback, questions proposals and extensions. http://www.ovirt.org/Feature/NetworkReloaded Best regards, Toni ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Sunday, January 6, 2013 11:03:59 AM Subject: Re: [vdsm] starting up vdsm and svdsm I think splitting VDSM and super VDSM into two services and delegate everything to systemd is simple and robust, just like libvirtd and VDSM. The auth key problem you mentioned also applies to connecting libvirtd, we can just follow the existing solution for it. I don't understand this auth key thing. Why is it required? Shouldn't it be sufficient to allow only vdsm user to interact with svdsm? Thanks, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Sunday, January 6, 2013 11:25:39 AM Subject: Re: [vdsm] starting up vdsm and svdsm on 01/06/2013 17:07, Alon Bar-Lev wrote: - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Sunday, January 6, 2013 11:03:59 AM Subject: Re: [vdsm] starting up vdsm and svdsm I think splitting VDSM and super VDSM into two services and delegate everything to systemd is simple and robust, just like libvirtd and VDSM. The auth key problem you mentioned also applies to connecting libvirtd, we can just follow the existing solution for it. I don't understand this auth key thing. Why is it required? Shouldn't it be sufficient to allow only vdsm user to interact with svdsm? Thanks, Alon. The auth key is not very useful. It is passed in the command arguments of super VDSM server, very insecure. By writing follow the existing solution, I mean libvirtd refer to a SASL DB for password and VDSM refer to /etc/pki/vdsm/keys/libvirt_password when connecting to libvirtd. I agree to allow only vdsm user to access the svdsm.sock and forget the auth key thing because saving the auth key in a vdsm user readonly file does not improve any security level. If the some one can access svdsm.sock, he can always access libvirt_password. libvirtd is mean to be used by many clients so its unix socket file can not be restricted to vdsm user only, it needs a password for each user in the SASL DB. The super VDSM server is only for VDSM itself, so restricting access svdsm.sock is enough, no auth key needed. Great. BTW: The auth key is not required even if you use multiple local users, as usock can ask the identity of the other party[1]. Alon [1] http://linux.die.net/man/7/unix SCM_CREDENTIALS ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - From: ybronhei ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Sunday, December 30, 2012 11:53:17 AM Subject: [vdsm] starting up vdsm and svdsm Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests * when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. Sounds like much correcter and easier to maintain design. I am not sure I understand why these two services are related. As far as I understand svdsm is a total stateless slave without any logic, to provide privilege escalation to vdsm. Why does it need to be restarted if vdsm changes state? I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend on that service. What am I missing? Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - From: ybronhei ybron...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Sunday, December 30, 2012 1:40:03 PM Subject: Re: [vdsm] starting up vdsm and svdsm On 12/30/2012 12:11 PM, Alon Bar-Lev wrote: - Original Message - From: ybronhei ybron...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Sunday, December 30, 2012 11:53:17 AM Subject: [vdsm] starting up vdsm and svdsm Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests * when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. Sounds like much correcter and easier to maintain design. I am not sure I understand why these two services are related. As far as I understand svdsm is a total stateless slave without any logic, to provide privilege escalation to vdsm. Why does it need to be restarted if vdsm changes state? I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend on that service. What am I missing? There is no relation between the states of the two. The only relation is that if one is up the other one must also be up and serve requests. for that case, systemd dependencies can solve the issue.. This is a dependency. Why the other when must also be up? From what I understand, there is no problem in having svdsm up anyway, hence no mutual dependency. If we do have mutual dependency we should work to eliminate that anyway. Instead of using systemd dependency and split the vdsmd service, I suggested to change the current relation and startup progress. Any benefit in that over using proper system services? Separate to two services that depended on each-other is another option to consider. Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Fwd: Bonding, bridges and ifcfg
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, December 10, 2012 3:16:21 PM Subject: Re: [vdsm] Fwd: Bonding, bridges and ifcfg On Mon, Dec 10, 2012 at 08:07:38AM -0500, Alon Bar-Lev wrote: Hi, Just to make sure... working in non-persistent mode will eliminate these kind of issues, right? No. It would eliminate the need to debug initscripts. But it would require vdsm developer of an intimate recognition of kernel quirks. We'd have fewer building blocks, and less of chance for incompatibility. But we would need to reimplement (some of) the logic within ifup script. Sure you need to reimplement ifup and ifdown functionality as you would not use these... You will not have fewer building blocks if you will break the fedora/redhat border, actually if you go non persistent you will have fewer of these and be more portable as you have one kernel (linux) to support. vdsm developer [should] already require intimate recognition of the kernel, see bellow one example. It is just that even if one has intimate recognition of the kernel, working via primitive tools like rhel/fedora network-script only make it harder to produce the desired outcome, while having full control over the process and the result. Alon - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, December 10, 2012 2:24:11 PM Subject: [vdsm] Fwd: Bonding, bridges and ifcfg Hello everybody, We found some unexpected behavior with bonds and we'd like to discuss it. Please, read the forwarded messages. Best, Toni - Forwarded Message - From: Dan Kenigsberg dan...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: Livnat Peer lp...@redhat.com, Igor Lvovsky ilvov...@redhat.com Sent: Monday, December 10, 2012 1:03:48 PM Subject: Re: Bonding, ifcfg and luck On Mon, Dec 10, 2012 at 06:47:58AM -0500, Antoni Segura Puimedon wrote: Hi all, I discussed this briefly with Livnat over the phone and mentioned it to Dan. The issue that we have is that, if I understand correctly our current configNetwork, it could very well be that it works by means of good design with a side-dish of luck. I'll explain myself: By design, as documented in http://www.kernel.org/doc/Documentation/networking/bonding.txt: All slaves of bond0 have the same MAC address (HWaddr) as bond0 for all modes except TLB and ALB that require a unique MAC address for each slave. Thus, all operations on the slave interfaces after they are added to the bond (except on TLB and ALB modes) that rely on ifcfg will fail with a message like: Device eth3 has different MAC address than expected, ignoring., and no ifup/ifdown will be performed. Currently, we were not noticing this, because we were ignoring completely errors in ifdown and ifup, but http://gerrit.ovirt.org/#/c/8415/ shed light on the matter. As you can see in the following example (bonding mode 4) the behavior is just as documented: [root@rhel64 ~]# cat /sys/class/net/eth*/address 52:54:00:a2:b4:50 52:54:00:3f:9b:28 52:54:00:51:50:49 52:54:00:ac:32:1b - [root@rhel64 ~]# echo +eth2 /sys/class/net/bond0/bonding/slaves [root@rhel64 ~]# echo +eth3 /sys/class/net/bond0/bonding/slaves [root@rhel64 ~]# cat /sys/class/net/eth*/address 52:54:00:a2:b4:50 52:54:00:3f:9b:28 52:54:00:51:50:49 52:54:00:51:50:49 - [root@rhel64 ~]# echo -eth3 /sys/class/net/bond0/bonding/slaves [root@rhel64 ~]# cat /sys/class/net/eth*/address 52:54:00:a2:b4:50 52:54:00:3f:9b:28 52:54:00:51:50:49 52:54:00:ac:32:1b - Obviously, this means that, for example, when we add a bridge on top of a bond, the ifdown, ifup of the bond slaves will be completely fruitless (although luckily that doesn't prevent them from working). Sorry, thi is not obvious to me. When we change something in a nic, we first take it down (which break it away from the bond), change it, and then take it up again (and back to the bond). I did not understand which flow of configuration leads us to the unexpected mac error. I hope that we can circumvent it. To solve this issue on the ifcfg based operation we could either: - Continue ignoring
Re: [vdsm] Fedora, udev and nic renaming
Thanks for this verbose description. I don't think using libguestfs is the solution for this. Fixing qemu to accept BIOS interface name at -net parameter is preferable. I don't think we should expose the interface a PCI device as it will have some drawbacks, but attempt to use the onboard convention. Alon - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Tuesday, December 4, 2012 11:08:31 AM Subject: [vdsm] Fedora, udev and nic renaming Hi, We are currently working on stabilizing the networking part of vdsm in Fedora 18 and, to achieve that purpose, we decided to test in in both physical hosts and, for extra convenience and better support, also in VMs. Due to the move of Fedora 17 and 18 to systemd and newer udev versions, we encountered some issues that should be noted and worked on to provide our users with a hassle-free experience. First of all, let me state what happens (in renaming) in RHEL-6.x when a new ethernet device is handled by udev: a) One or more udev rules match the characteristics of the interface: The last matching rule is applied. b) No rule is matching: /lib/udev/write-net-rules writes a permanent rule using the MAC address of the interface in a udev rules file, so the interface name will be permanent and in the ethX namespace. In Fedora 17 (but even more so in F18), with the move to a newer version of udev and, specially, with the change from sysV init to systemd, the mechanism changed. Since systemd is making the boot happen in a parallelized way, some changes had to be enforced in udev to keep the renaming working: - To avoid naming collisions, it was decided to use Dell's biosdevname software to retrieve a device name for the network interfaces. Typically emX for onboard nics and pXpY for pci connected nics. - For devices which biosdevname could not provide any information, it was agreed to assign them a name in the ethX space in a first-come, first-served fashion. - Optionally, one could define the interace MAC addr in an ifcfg file and /lib/udev/rename-device would look into the ifcfg file and assign the device name there set (I have not yet succeeded in that part, I have to investigate more, I guess). As you can see, biosdevname, never reports names in the eth space to avoid collision with a potential parallel discovery of an interface not recognizable by it, to which the kernel could have assigned already a bios reported name. For physical machines this approach works fine. However, for Virtual machines with more than one nic, the automatic process described above presents some issues. Biosdevname, due to the different ways the virtualization hypervisors report the vnics, dropped support for VMs in 0.3.7 (F18 uses 0.4.1-2) and decided that on VMs, it would just return 4 to indicate to udev to use kernel first-come, first-served for those interfaces (ethX namespace). The issue with using first-come first-served, is that due to the highly parallelized boot there is now, it is very common to encounter that the names of your devices (as identified by MAC address) suffer a permutation upon each reboot. Here you can see an example: NOTE: The libvirt dump of the VM reports the same PCI address for each interface across reboots. Boot 0 (Nov 13th 14:59) eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:54:85:57 txqueuelen 1000 (Ethernet) eth1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:77:45:6b txqueuelen 1000 (Ethernet) eth2: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:ca:41:c7 txqueuelen 1000 (Ethernet) eth3: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:f5:3d:c8 txqueuelen 1000 (Ethernet) eth4: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:5e:10:76 txqueuelen 1000 (Ethernet) eth5: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:95:00:93 txqueuelen 1000 (Ethernet) Boot 1 (Nov 13th 15:01) eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:ca:41:c7 txqueuelen 1000 (Ethernet) eth1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:54:85:57 txqueuelen 1000 (Ethernet) eth2: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:77:45:6b txqueuelen 1000 (Ethernet) eth3: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:f5:3d:c8 txqueuelen 1000 (Ethernet) eth4: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:5e:10:76 txqueuelen 1000 (Ethernet) eth5: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 ether 52:54:00:95:00:93 txqueuelen 1000 (Ethernet) As you can see, after rebooting: eth0 - eth1
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On 11/28/2012 01:20 PM, Saggi Mizrahi wrote: ... VDSM should not bother with the issue at all, certainly not playing a guessing game. Livant, your 0.02$? This exactly the reason why we should either define completely stateless slave host, and apply configuration including what you call 'defaults'. Completely stateless is problematic because if the engine is down or unavailable and VDSM happens to restart you can't use any of your resources. that's actually a very good point. going forward we would like to be able for hosts to continue working when engine is down, even post reboot. engine passing the policy to the hosts and hosts assuming that policy is relevant post boot would allow that. (though relying on central network services like qunatum will also cause an issue for this architecture). The way forward is currently to get rid of most of the configuration in vdsm.conf. Only have things that are necessary for communication with the engine (eg. Core dump on\off, management interface\port, SSL on\off). Other VDSM configuration should have a an API introduced to set them and that will be persisted but only configurable by management (eg. reserved host mem, guest ram overhead, migration timeouts). There should be a place where VDSM saves the configuration of owned resources (eg. managed storage connections, managed interfaces). This will be use by VDSM to make sure that the resources are configured properly after restarts\downtimes without the need of the engine. To reiterate, the general logic for system resources should be that resources are either owned or used by VDSM, you never share ownership. Never assume ownership unless expressly given. VDSM has complete control over owned resources. VDSM has NO control over unowned resources, he can use them but never configure them. Every other hybrid scheme is just asking for trouble. Or, store configuration before we perform any change so we can revert. Assuming manual changes and distro specific persistence make the problem complex in factor of np complete, as we do not know what was changed when and how to revert. Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. It's all about resource provisioning and ownership delegation. hybrid mode is something brought up several times as a use case we should consider. so far our main concern was that SLA in the host would be needed (cgroup for example) between the native and guest workloads. as well as making sure hybrid nodes will not contend for critical resources to reduce the risk of a need to fence them. brought up - ok. should be supported - this is the question. there is no problem to wrap the original server within vm and solve the problem with current terms. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip Assuming manual changes and distro specific persistence make the problem complex in factor of np complete, as we do not know what was changed when and how to revert. Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. This is not the way to go in this case, Oracle will not live within stateless world, nor 1000 other solutions. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:35:46 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Simon Grinberg si...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 29, 2012 2:25:03 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Simon Grinberg si...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, November 29, 2012 2:12:09 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Itamar Heim ih...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Andrew Cathrow acath...@redhat.com Sent: Thursday, November 29, 2012 1:06:29 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. snip Assuming manual changes and distro specific persistence make the problem complex in factor of np complete, as we do not know what was changed when and how to revert. Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. Just few reasons: - One of the key attraction with KVM is that with it, you are capable to run process/application along side virtual machines. Look at every KVM presentation out there. - Licencing and support, some application (do I hear Oracle?) are not licensed/supported on KVM, but you would still want to use free cycles for virtual machines (especially on modern servers) - 3rd party monitoring and audit tools - custom drivers - custom SLA policies - etc, - etc, - etc, You don't want to say, ha if you use VDSM to manage the node you can't do all of the above. Actually, I am. I claim that we will never be able to stabilize a product if we go this way. There is a very good reason why other virtualization solutions out there put similar restriction. When and if we finish with rock solid solution using a pure completely managed slave and have good market share then we can start thinking about these non deterministic approaches. Actually it's the other way around. Since you are far from there, then many (if not most) users today actually use a full blown host to complement features or required functionality like: Monitoring, Private firewall, central logging, customization for third party devices etc. And again, I disagree. This may be enough for an entry level solution. Enterprise solution will probably prefer rhev-h or similar self managed solution, this of course, if we provide decent management support. Customization for third party devices has no management/state impact. Central logging - we have the log collector for that. Monitoring - if we going to provide SLA we are going to perform monitoring as well. Private Firewall - this will totally conflict with whatever engine enforces. Or... maybe this is the marketing advantage we would like, and then we should FOCUS on this approach, but then we are aiming to low scale, manual managed solution, and the other open source project will probably consume the higher scale. As I wrote there are two solution using CURRENT technology for that: 1. Move the original host into virtual machine and manage the host as a whole. 2. Execute virtual machine with nested virtualization and manage this VM as if it was our host, in this mode we have no conflict. Stateless by the way, in a sense that after reboot the node goes back to the original configuration, works very well with the requirement above. This means that the admin sets everything required for the non virtualized hardware, VDSM configures on top, but after reboot all is reverted to the original thus everything else continues to work after reboot. This is not the way to go in this case, Oracle will not live within stateless world, nor 1000 other solutions. You missed what I've said: Admin configures state-fully everything required for the 'native' application, VDSM may configure starless on top. After reboot, host goes back to the original configuration that is enough to run the 'native' non managed by VDSM applications. No I did not. Let's say we
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Itamar Heim ih...@redhat.com To: Roni Luxenberg rluxe...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 2:01:45 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/28/2012 05:34 AM, Roni Luxenberg wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Yaniv Kaul yk...@redhat.com Sent: Wednesday, November 28, 2012 11:01:35 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/28/2012 03:53 AM, Dan Kenigsberg wrote: On Tue, Nov 27, 2012 at 03:24:58PM -0500, Alon Bar-Lev wrote: Management interface configuration is a separate issue. But it is an important issue that has to be discussed.. If we perform changes of this interface when host is in maintenance we reduce the complexity of the problem. For your specific issue, if there are two interfaces, one which is up during boot and one which is down during boot, there is no problem to bond them after boot without persisting configuration. how would you know which bond mode to use? which MTU? I don't understand the question. I think I do: Alon suggests that on boot, the management interface would not have bonding at all, and use a single nic. The switch would have to assume that other nics in the bond are dead, and will use the only one which is alive to transfer packets. There is no doubt that we have to persist the vlan tag of the management interface, and its MTU, in the extremely rare case where the network would not alow Linux's default of 1500. i was thinking manager may be using jumbo frames to talk to host, and host will have an issue with them since it is set to 1500 instead of 8k. jumbo frames isn't a rare case. as for bond, are you sure you can use a nic in a non bonded mode for all bond modes? all bond modes have to cope with a situation where only a single nic is active and the rest are down, so one can boot with a single active nic and only activate the rest and promote to the desired bond mode upon getting the full network configuration from the manager. of course they need to handle single active nic, but iirc, the host must be configured for a matching bond as the switch. i.e., you can't configure the switch to be in bond, then boot the host with a single active nic in a non bonded config as far as I know as long as the 2nd nic is down there is no problem. it is as if the cord is out. Changing the master interface mtu for either vlan or bond is required for management interface and non management interface. So the logic would probably be set max(mtu(slaves)) regardless it is management interface or not. I discussed this with Livnat, if there are applications that access the master interface directly we may break them, as the destination may not support non standard mtu. This is true in current implementation and any future implementation. It is bad practice to use the master interface directly (mixed tagged/untagged), better to define in switch that untagged communication belongs to vlanX, then use this explicit vlanX at host. next, what if we're using openvswitch, and you need some flow definitions for the management interface? I cannot answer that as I don't know openvswitch very well and don't know what flow definitions are, however, I do guess that it has non persistent mode that can effect any interface on its control. If you like I can research this one. you mainly need OVS for provisioning VM networks so here too you can completely bypass OVS during boot and only configure it in a transactional manner upon getting the full network configuration from the manager. a general question, why would you need to configure VM networks on the host (assuming a persistent cached configuration) upon boot if it cannot talk to the manager? after-all, in this case no resources would be scheduled to run on this host until connection to the manager is restored and up-to-date network configuration is applied. thanks, Roni ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
Hello All, Preparing to ovirt-engine 3.2 the entire vdsm-bootstrap bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots. As far as packaging is concerned there are now two more dependencies to ovirt-engine: * otopi -- oVirt Task Oriented Pluggable Installer/Implementation * ovirt-host-deploy -- oVirt host deploy tool These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm. Git repositories are available at at[1][2]. Documentation is available at Git repositories - README*. Builds are available at usual place[3]. Bugzilla components will be available shortly. Change log is attached. There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved. The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine. Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests. The internals are completely different, instead of having 3 different bootstrap sequences: 1. host install 2. ovirt-node install 3. ovirt-node approve We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation. Please report any issues even minor issues, so we can stabilize it for 3.2 release. Best Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ --- Change Log * offline packager feature. * tuned is installed with virtual-host profile. * initial implementation based on otpoi. * implementation is based on legacy vdsm-bootstrap pacakge functionality. * legacy-removed: legacy VDSM (3.0) config upgrade. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core /proc/sys/kernel/core_pattern * legacy-removed: kernel version test, package dependency is sufficient. * legacy-removed: do not add kernel parameter processor.max_cstate=1 warn if not have constant_tsc https://bugzilla.redhat.com/show_bug.cgi?id=770153 * legacy-change: io elevator scheduler set in kernel command-line use either udev rule in vdsm package or tuned. * legacy-change: vdsm libvirt reconfigure vdsm is reconfigured with file based trigger instead unsupported systemd init.d parameter. * legacy-change: distribution checks are simpler based on Python platform, minimum: - rhel-6.2 - fedora-17 * legacy-change: minimum vdsm version is taken from engine not hard coded. * legacy-change: pki is now using m2crypto to generate certificate request and parse certificates. * legacy-change: use iproute2 instead of python ethtool to avoid another dependency for host name validation. * legacy-change: use iproute2 instead of reading /proc/net/route for route information and interface information. * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires /usr/share/vdsm modules, and it is trivial anyway. * legacy-change: use vdsm-store-net-config script to commit network config instead of internal duplicate implementation. * legacy-change: /etc/vdsm/vdsm.conf is overridden unless VDSM/configOverride environment is set to True * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu. set VDSM/checkVirtHardware environment to False to avoid hardware detection. * legacy-change: following gluster packages not installed: - glusterfs-rdma - glusterfs-geo-replication ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, engine-devel engine-de...@ovirt.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 4:41:04 PM Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote: Hello All, Preparing to ovirt-engine 3.2 the entire vdsm-bootstrap bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots. As far as packaging is concerned there are now two more dependencies to ovirt-engine: * otopi -- oVirt Task Oriented Pluggable Installer/Implementation * ovirt-host-deploy -- oVirt host deploy tool These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm. Hurray! I suspect that a `git-rm vds_bootstrap/*` is pending? No... we need it as compatibility with older engines... We keep minimum changes there for legacy, until end-of-life. Git repositories are available at at[1][2]. Documentation is available at Git repositories - README*. Builds are available at usual place[3]. Bugzilla components will be available shortly. Are there requests to add the components to Fedora (18, EPEL6)? I think we should add these requests as blockers for Bug 881006 - Tracker: oVirt 3.2 release. Yes, I am on this one. Change log is attached. There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved. The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine. Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests. The internals are completely different, instead of having 3 different bootstrap sequences: 1. host install 2. ovirt-node install 3. ovirt-node approve We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation. Please report any issues even minor issues, so we can stabilize it for 3.2 release. Best Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ --- Change Log * offline packager feature. * tuned is installed with virtual-host profile. I never understood why this is an installer step, and not part of vdsmd start up There may be several method to tune a machine. Why VDSM should depend on specific one? * initial implementation based on otpoi. * implementation is based on legacy vdsm-bootstrap pacakge functionality. * legacy-removed: legacy VDSM (3.0) config upgrade. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core /proc/sys/kernel/core_pattern Yeah, qemu-kvm and libvirtd are much more stable than in the old days, but wouldn't we want to keep a means to collect the corpses of dead processes from hypervisors? It has helped us nail down nasty bugs, even in Python. It does not mean it should be at /var/lib/vdsm ... :) * legacy-removed: kernel version test, package dependency is sufficient. * legacy-removed: do not add kernel parameter processor.max_cstate=1 warn if not have constant_tsc https://bugzilla.redhat.com/show_bug.cgi?id=770153 * legacy-change: io elevator scheduler set in kernel command-line use either udev rule in vdsm package or tuned. * legacy-change: vdsm libvirt reconfigure vdsm is reconfigured with file based trigger instead unsupported systemd init.d parameter. * legacy-change: distribution checks are simpler based on Python platform, minimum: - rhel-6.2 - fedora-17 * legacy-change: minimum vdsm version is taken from engine not hard coded. * legacy-change: pki is now using m2crypto to generate certificate request and parse certificates. * legacy-change: use iproute2 instead of python ethtool to avoid another dependency for host name validation. * legacy-change: use iproute2 instead of reading /proc/net/route for route information and interface information. * legacy-change: do not use vdsm.netinfo for vlan and bonding as it requires /usr/share/vdsm modules, and it is trivial anyway. * legacy
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Simon Grinberg si...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, lpeer Livnat Peer lp...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 7:37:48 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: Simon Grinberg si...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 7:15:35 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Simon Grinberg si...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Barak Azulay bazu...@redhat.com, Igor Lvovsky ilvov...@redhat.com Sent: Wednesday, November 28, 2012 12:03:03 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: Igor Lvovsky ilvov...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Simon Grinberg si...@redhat.com, Barak Azulay bazu...@redhat.com Sent: Wednesday, November 28, 2012 6:49:22 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. OK, I think I need to explain myself better, MTU sizes under 1500 are not interesting as they are only really valid for slow networks which will not be able to support virt workloads anyway. 1500 is internet MTU and is the recommended size when communicating with the outside world. MTU is just a size that has to be agreed upon by all participants in the chain. There is no inherent default MTU but default is technically 1500. Reverting to previous value makes no sense unless you are just testing something out. Yes it does, There are networks out there that do use MTU 1500 as weird as it sounds, It not weird at all, this is why MTU settings exist. But setting a low MTU will not break the network but will just have some performance degredation. this usually the admin does initial settings on the management network and then when you set don't touch all works well. An example is when you have storage and management on the same network. Now consider the scenario that for some VMs the user wants to limit to the 'normal/recommended defaults' so in this case he will have to set in the logical network property to MTU=1500. when VDSM sets this chain it supposedly won't touch the interface MTU since it's already bigger (if it does it's a bug). Now the user has one more logical network of VMs with 9000 since he also have VMs using shared storage on this network. All works well till now. But what about when removing the 9000 network? Will VDSM 'remember' that it did not touch the interface MTU in the first place, or will it try to set it to this recommended MTU?. It's a question of ownership. Because it's simpler I suggest we assume ownership and always set the maximum needed (also lowering if to high). The engine can query the MTU and make weird decision according. Like setting the current as default or as a saved value or whatever. This flow obviously needs user input so VSDM is not the place to put the decision making. I tend to agree, it's an ownership thing Engine should not allow mixed configuration of 'default vs override' on the same interface. If user wishes to start playing with MTUs he needs to use it carefully and across the board. VDSM should not bother with the issue at all, certainly not playing a guessing game. Livant, your 0.02$? This exactly the reason why we should either define completely stateless slave host, and apply configuration including what you call 'defaults'. Or, store configuration before we perform any change so we can revert. Assuming manual changes and distro specific persistence make the problem complex in factor of np complete, as we do not know what was changed when and how to revert. Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. Alon I have no idea :) For that case the engine can remember the current MTU and set it back. To sum up, I suggest ignoring any previously set value like we would ignore it if VDSM had set it. It makes no sense to keep it because the semantic of setting the MTU is to override the current configuration. As a side note, having verb to test max MTU for a path might be a good idea to give the engine\user a way to recommend a value to the user. That is
Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, engine-devel engine-de...@ovirt.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 9:48:41 PM Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) On Wed, Nov 28, 2012 at 09:45:17AM -0500, Alon Bar-Lev wrote: On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote: Hello All, Preparing to ovirt-engine 3.2 the entire vdsm-bootstrap bootstrap was re-written from scratch into more pluggable and flexible implementation, available at git master and nightly snapshots. As far as packaging is concerned there are now two more dependencies to ovirt-engine: * otopi -- oVirt Task Oriented Pluggable Installer/Implementation * ovirt-host-deploy -- oVirt host deploy tool These packages replace the legacy vdsm-bootstrap package that was distributed with vdsm. Hurray! I suspect that a `git-rm vds_bootstrap/*` is pending? No... we need it as compatibility with older engines... We keep minimum changes there for legacy, until end-of-life. Is there an EoL statement for oVirt-3.1? We can make sure that oVirt-3.2's vdsm installs properly with ovirt-3.1's vdsm-bootstrap, or even require that Engine must be upgraded to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to our vast install base? us...@ovirt.org, please chime in! I tried to find such, but the more I dig I find that we need to support old legacy. Git repositories are available at at[1][2]. Documentation is available at Git repositories - README*. Builds are available at usual place[3]. Bugzilla components will be available shortly. Are there requests to add the components to Fedora (18, EPEL6)? I think we should add these requests as blockers for Bug 881006 - Tracker: oVirt 3.2 release. Yes, I am on this one. Change log is attached. There is no change in the way the engine is performing the host deployment process in term of user experience, other than event log messages during deployment were improved. The log of the deployment is fetched from host and stored at engine machine at /var/log/ovirt-engine/host-deploy, on host it is at /tmp/ovirt-host-deploy*.log and deleted when fetched to engine. Among other features, the ovir-host-deploy package can be installed manually on host and executed to prepare host for installation, in future we may be able to add host to engine without performing the deployment process, for now it will be usable for integration tests. The internals are completely different, instead of having 3 different bootstrap sequences: 1. host install 2. ovirt-node install 3. ovirt-node approve We now have single sequence which is common to host and node installation or re-installation, end result is much simpler implementation. Please report any issues even minor issues, so we can stabilize it for 3.2 release. Best Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree [2] http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ --- Change Log * offline packager feature. * tuned is installed with virtual-host profile. I never understood why this is an installer step, and not part of vdsmd start up There may be several method to tune a machine. Why VDSM should depend on specific one? Maybe because I tend to install vdsm using `yum`, and would like it to do The Right Thing to make the host an oVirt node. I suspect that if ovirt-host-deploy proves to be easy to use, I could follow my `yum install vdsm` with `ovirt-host-deploy`. I will be glad if you try it out. * initial implementation based on otpoi. * implementation is based on legacy vdsm-bootstrap pacakge functionality. * legacy-removed: legacy VDSM (3.0) config upgrade. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core /proc/sys/kernel/core_pattern Yeah, qemu-kvm and libvirtd are much more stable than in the old days, but wouldn't we want to keep a means to collect the corpses of dead processes from hypervisors? It has helped us nail down nasty bugs, even in Python. It does not mean it should be at /var/lib/vdsm ... :) I don't get the joke :-(. If you mind the location, we can think of somewhere else to put the core dumps. Would it be hard to reinstate a parallel feature in otopi? I usually do not make any jokes... A global system setting should not go
Re: [vdsm] MTU setting according to ifcfg files.
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Simon Grinberg si...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 10:20:11 PM Subject: Re: [vdsm] MTU setting according to ifcfg files. On Wed, Nov 28, 2012 at 12:49:10PM -0500, Alon Bar-Lev wrote: Itamar though a bomb that we should co-exist on generic host, this is something I do not know to compute. I still waiting for a response of where this requirement came from and if that mandatory. This bomb has been ticking since ever. We have ovirt-node images for pure hypervisor nodes, but we support plain Linux nodes, where local admins are free to `yum upgrade` in the least convenient moment. The latter mode can be the stuff that nightmares are made of, but it also allows the flexibility and bleeding-endgeness we all cherish. There is a different between having generic OS and having generic setup, running your email server, file server and LDAP on a node that running VMs. I have no problem in having generic OS (opposed of ovirt-node) but have full control over that. Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, engine-devel engine-de...@ovirt.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 10:39:42 PM Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote: No... we need it as compatibility with older engines... We keep minimum changes there for legacy, until end-of-life. Is there an EoL statement for oVirt-3.1? We can make sure that oVirt-3.2's vdsm installs properly with ovirt-3.1's vdsm-bootstrap, or even require that Engine must be upgraded to ovirt-3.2 before upgrading any of the hosts. Is it too harsh to our vast install base? us...@ovirt.org, please chime in! I tried to find such, but the more I dig I find that we need to support old legacy. Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an unupgradable F16). Should we be any better than our (currently single) platform? We should start and detach from specific distro procedures. * legacy-removed: change machine width core file # echo /var/lib/vdsm/core /proc/sys/kernel/core_pattern Yeah, qemu-kvm and libvirtd are much more stable than in the old days, but wouldn't we want to keep a means to collect the corpses of dead processes from hypervisors? It has helped us nail down nasty bugs, even in Python. It does not mean it should be at /var/lib/vdsm ... :) I don't get the joke :-(. If you mind the location, we can think of somewhere else to put the core dumps. Would it be hard to reinstate a parallel feature in otopi? I usually do not make any jokes... A global system setting should not go into package specific location. Usually core dumps are off by default, I like this approach as unattended system may fast consume all disk space because of dumps. If a host fills up with dumps so quickly, it's a sign that it should not be used for production, and that someone should look into the cores. (P.S. we have a logrotate rule for them in vdsm) There should be a vdsm-debug-aids (or similar) to perform such changes. Again, I don't think vdsm should (by default) modify any system width parameter such as this. But I will happy to hear more views. If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... If we want to automatically enable dumps I guess it should go to /var/lib/core or similar. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, Dan Kenigsberg dan...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, November 28, 2012 11:59:29 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) * Alon Bar-Lev alo...@redhat.com [2012-11-28 15:33]: Leaving only vdsm-devel. - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, engine-devel engine-de...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org, users us...@ovirt.org Sent: Wednesday, November 28, 2012 11:22:59 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) snip If sysadmin manually enables dumps, he may do this at a location of his own choice. Note that we've just swapped hats: you're arguing for letting a local admin log in and mess with system configuration, and I'm for keeping a centralized feature for storing and collecting core dumps. As problems like crashes are investigated per case and reproduction scenario. But again, I may be wrong and we should have VDSM API command to start/stop storing dumps and manage this via its master... I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 Yes, I read this, however, I am unsure that debug and low level collections should be implemented as in-band interface and not side-band. After many of years handling crappy bug reports that don't include the data needed for debugging, such as log files and other settings, and spending weeks going back and forth with the submitter on collecting what and where and how to collect it, I'm confident that having something that can programtically enable debugging on-demand and providing a way to collect the relative data (logs, cores, etc) would make a dramatic improvement when handing these support issues. I'm also a firm believer in lowering the barriers for consumption. IIUC, a side-band tool is going to require additional configuration/authenitication; and will ultimately need to access the API anyhow to determine various information about the specific VM. With that in mind, why wouldn't we want to look at a first-class debug API mode which can be used remotely and programatically? A better question is, what are the drawbacks to having it in-band? You took it too far... :) The problem with *THE* API is that there is a contract for forward/backward stability. From my experience having first class API for production is good as long as it is not being dragged for other purposes. You can always have second class API for debugging. The advantage of this is that the second class API is much more flexible and can serve strange/none standard (not fully compliant entities. It does not mean you don't reuse your code and/or authentication... Having said that... I think that most of this can be done via simple SSH and proper command-line tool at host side, which is very simple to use and implement. But I did not intend to (re)open the discussion about the debug API :) Regrds, Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Livnat Peer lp...@redhat.com To: Adam Litke a...@us.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:42:00 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 16:59, Adam Litke wrote: On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote: On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. I worry a lot about the above if we take the dynamic approach. It seems we'd need to introduce before/after 'apply network configuration' hooks where the admin could add custom config commands that aren't yet modeled by engine. yes, and I'm not sure the administrators would like the fact that we are 'forcing' them to write everything in a script and getting familiar with VDSM hooking mechanism (which in some cases require the use of custom properties on the engine level) instead of running a simple command line. In which case will we force? Please be more specific. If we can pass most of the iproute2, brctl, bond parameters via key/value pairs via the API, what in your view that is common or even seldom should be used? This hook mechanism is only as fallback, provided to calm people down. Any other approaches ? Static configuration has the advantage of allowing a host to bring itself back online independent of the engine. This is also useful for anyone who may want to deploy a vdsm node in standalone mode. I think it would be possible to easily support a quasi-static configuration mode simply by extending the design of the dynamic approach slightly. In dynamic mode, the network configuration is passed down as a well
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Livnat Peer lp...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Shu Ming shum...@linux.vnet.ibm.com, Saggi Mizrahi smizr...@redhat.com, Dan Kenigsberg dan...@redhat.com Sent: Tuesday, November 27, 2012 12:18:31 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 22:18, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Livnat Peer lp...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 4:22:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary snip Livnat, I don't see any argument of persistence vs non persistence as the above is common to any approach taken. Only this manual configuration argument keeps poping, which as I wrote is irrelevant in large scale and we do want to go into large scale. Well, we call it manual configuration, but it applies just as well to puppet-based configuration. Dan. There can by only one (manager to each host). Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:08:34 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/26/2012 03:18 PM, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce complexity of implementation, so that only one algorithm is used in order
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:19:51 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/27/2012 03:17 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 10:08:34 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 11/26/2012 03:18 PM, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
- Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some more expansion. ASSUMPTION After boot a host running vdsm is able to receive communication from engine. This means that host has legitimate layer 2 configuration and layer 3 configuration for the interface used to communicate to engine. MISSION Reduce complexity of implementation, so that only one algorithm is used in order to reach to operative state as far as networking is concerned. (Storage is extremely similar I can s/network/storage/ and still be relevant). DESIGN FOCAL POINT Host running vdsm is a complete slave of its master, will it be ovirt-engine or other engine. Having a complete slave ease implementation: 1. Master always apply the setting as-is. 2. No need to consider slave state. 3. No need to implement AI to reach from unknown state X to known state Y + delta. 4
Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
Hello, - Original Message - From: Adam Litke a...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Livnat Peer lp...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, November 27, 2012 12:51:36 AM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary Nice writeup! I like where this is going but see my comments inline below. On Mon, Nov 26, 2012 at 03:18:22PM -0500, Alon Bar-Lev wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Shu Ming shum...@linux.vnet.ibm.com Cc: Alon Bar-Lev abar...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, November 26, 2012 2:57:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary On 26/11/12 03:15, Shu Ming wrote: Livnat, Thanks for your summary. I got comments below. 2012-11-25 18:53, Livnat Peer: Hi All, We have been discussing $subject for a while and I'd like to summarized what we agreed and disagreed on thus far. The way I see it there are two related discussions: 1. Getting VDSM networking stack to be distribution agnostic. - We are all in agreement that VDSM API should be generic enough to incorporate multiple implementation. (discussed on this thread: Alon's suggestion, Mark's patch for adding support for netcf etc.) - We would like to maintain at least one implementation as the working/up-to-date implementation for our users, this implementation should be distribution agnostic (as we all acknowledge this is an important goal for VDSM). I also think that with the agreement of this community we can choose to change our focus, from time to time, from one implementation to another as we see fit (today it can be OVS+netcf and in a few months we'll use the quantum based implementation if we agree it is better) 2. The second discussion is about persisting the network configuration on the host vs. dynamically retrieving it from a centralized location like the engine. Danken raised a concern that even if going with the dynamic approach the host should persist the management network configuration. About dynamical retrieving from a centralized location, when will the retrieving start? Just in the very early stage of host booting before network functions? Or after the host startup and in the normal running state of the host? Before retrieving the configuration, how does the host network connecting to the engine? I think we need a basic well known network between hosts and the engine first. Then after the retrieving, hosts should reconfigure the network for later management. However, the timing to retrieve and reconfigure are challenging. We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat Sorry for the delay. Some
Re: [vdsm] Future of Vdsm network configuration
- Original Message - From: David Jaša dj...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-de...@fedorahosted.org Sent: Monday, November 12, 2012 7:13:19 PM Subject: Re: [vdsm] Future of Vdsm network configuration Hi Alon, Alon Bar-Lev píše v Ne 11. 11. 2012 v 13:28 -0500: - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-de...@fedorahosted.org, Dan Kenigsberg dan...@redhat.com Sent: Sunday, November 11, 2012 5:47:54 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: vdsm-de...@fedorahosted.org Sent: Sunday, November 11, 2012 3:46:43 PM Subject: Re: [vdsm] Future of Vdsm network configuration - Original Message - From: Dan Kenigsberg dan...@redhat.com To: vdsm-de...@fedorahosted.org Sent: Sunday, November 11, 2012 4:07:30 PM Subject: [vdsm] Future of Vdsm network configuration Hi, Nowadays, when vdsm receives the setupNetowrk verb, it mangles /etc/sysconfig/network-scripts/ifcfg-* files and restarts the network service, so they are read by the responsible SysV service. This is very much Fedora-oriented, and not up with the new themes in Linux network configuration. Since we want oVirt and Vdsm to be distribution agnostic, and support new features, we have to change. setupNetwork is responsible for two different things: (1) configure the host networking interfaces, and (2) create virtual networks for guests and connect the to the world over (1). Functionality (2) is provided by building Linux software bridges, and vlan devices. I'd like to explore moving it to Open vSwitch, which would enable a host of functionalities that we currently lack (e.g. tunneling). One thing that worries me is the need to reimplement our config snapshot/recovery on ovs's database. As far as I know, ovs is unable to maintain host level parameters of interfaces (e.g. eth0's IPv4 address), so we need another tool for functionality (1): either speak to NetworkManager directly, or to use NetCF, via its libvirt virInterface* wrapper. I have minor worries about NetCF's breadth of testing and usage; I know it is intended to be cross-platform, but unlike ovs, I am not aware of a wide Debian usage thereof. On the other hand, its API is ready for vdsm's usage for quite a while. NetworkManager has become ubiquitous, and we'd better integrate with it better than our current setting of NM_CONTROLLED=no. But as DPB tells us, https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html we'd better offload integration with NM to libvirt. We would like to take Network configuration in VDSM to the next level and make it distribution agnostic in addition for setting the infrastructure for more advanced features to be used going forward. The path we think of taking is to integrate with OVS and for feature completeness use NetCF, via its libvirt virInterface* wrapper. Any comments or feedback on this proposal is welcomed. Thanks to the oVirt net team members who's input has helped writing this email. Hi, As far as I see this, network manager is a monster that is a huge dependency to have just to create bridges or configure network interfaces... It is true that on a host where network manager lives it would be not polite to define network resources not via its interface, however I don't like we force network manager. NM is a default way of network configuration from F17 on and it's available on all platforms. It isn't exactly small but it wouldn't pull any dependency AFAICT because all its dependencies are on Fedora initramfs already... libvirt is long not used as virtualization library but system management agent, I am not sure this is the best system agent I would have chosen. I think that all the terms and building blocks got lost in time... and the result integration became more and more complex. Stabilizing such multi-layered component environment is much harder than monolithic environment. I would really want to see vdsm as monolithic component with full control over its resources, I believe this is the only way vdsm can be stable enough to be production grade. Hypervisor should be a total slave of manager (or cluster), so I have no problem
Re: [vdsm] [VDSM][RFC]Switch of VDSM tarball compression format: tar.xz only
- Original Message - From: Dave Neary dne...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, November 9, 2012 12:42:51 PM Subject: Re: [vdsm] [VDSM][RFC]Switch of VDSM tarball compression format: tar.xz only Hi, On 11/05/2012 10:22 AM, Dan Kenigsberg wrote: I don't really understand your motivation. I also think that supporting gzip is important. Practically every open source project on the face of this planet, ships its source as a gzip'ed tarball. Which projects use xz for that? xz is the new hot compression (like 7zip was a few years ago, and bz2 was before it). GNOME has switched to xz tarballs only: https://mail.gnome.org/archives/devel-announce-list/2011-September/msg3.html and other projects are moving in the same direction. Gnome is not example for anything... but apart of that this project contains a lot of binary artifacts and huge distribution, which is totally unrelated to vdsm. In most cases hot != best Alon ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] ipv6 support of vdsm
- Original Message - From: huntxu mhun...@gmail.com To: vdsm-devel@lists.fedorahosted.org Sent: Thursday, November 8, 2012 12:58:09 PM Subject: [vdsm] [RFC] ipv6 support of vdsm Hi, folks. Recently I am considering to implement ipv6 support for vdsm. First of all I would like to know whether there is already someone working on this feature. If so, I might do something to help, however, if not, I would try to implement it with suggestions from this discussion. With ipv6 support vdsm is supposed to work properly in: * mixed environment, in which ipv4 and ipv6 addresses coexist * ipv6-pure environment My idea is: 1) Provide a mechanism to setup ipv6 address configuration of a host via XMLRPC/RestAPI. This would be done in the current ConfigNetwork module by modifying the network-scripts/ifcfg-* of the devices. Thus the host is able to access ipv6 network (with correct configuration). 2) For incoming spice connections, qemu is able to listen to ipv6 address, so we use a boolean option spice_use_ipv6 which indicates whether qemu should listen to incoming ipv6 or ipv4 connections. 3) Make the connection with ovirt-engine(management connection) also ipv6- compatible. This requires modifying both XMLRPC and RestAPI servers to make them able to bind to the ipv6 address of the host. Also we need another boolean option use_ipv6 to indicate what is the ip version of the management connection. 4) Regarding the register process, all is the same with the current workflow, except for if we use ipv6 to register, we should firstly set use_ipv6 to True, then XMLRPC and RestAPI servers would be listening on the ipv6 address after vdsm restarts. 5) The management connection is supposed to be able to switch between ipv4 and ipv6 on the fly (when host is under maintenance and with proper network configuration of the host). This requires another vdsm API. Suggestions are always welcome. Thanks. This is great, although I don't understand why not listening to all incoming communication? Why does the application cares if it is connected from ipv4 or ipv6? it should accept any connection. If we can put ACL of valid sources, and then be ip type aware, but it is not implemented currently as far as I know, so no need to add this now. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all'
- Original Message - From: Doron Fediuck dfedi...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, vdsm-devel@lists.fedorahosted.org, Ryan Harper ry...@us.ibm.com, Ayal Baron aba...@redhat.com Sent: Tuesday, October 2, 2012 2:28:07 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Ryan Harper ry...@us.ibm.com Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron Fediuck dfedi...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, October 1, 2012 10:53:31 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' - Original Message - From: Ryan Harper ry...@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron Fediuck dfedi...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Monday, October 1, 2012 10:24:08 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' * Alon Bar-Lev alo...@redhat.com [2012-09-27 13:38]: Alon Bar-Lev has posted comments on this change. Change subject: Use 'yum clean expire-cache' instead of 'yum clean all' .. Patch Set 2: Ok... I was discussing... I think that if you don't get +1 from parties you should wait... :) I see -1 as final decision... for the entire change... or if contributer is not cooperating. I'm interested in a little clarity here. As I see it, -1 means you don't want the current version submitted. I like the idea of putting a patch on hold while various issues are discussed, and it seems like a -1 is the right idea here since the submitter can reply and original reviewer can re-review and remove a -1 if the submitter has fully explained the issue. Additionaly the submitter can resubmit with changes (and the -1 is removed anyhow). This is exactly the problem... you cannot rely on -1 as it clears if a new patchset is pushed. Only +1 is to be considered before merge. What is the maintainer view of how best to use -1? And if we don't use a -1, how does one do the above? I think that this is fairly new to have proper procedure set. There are people who use -1 as labelling of what they reviewed. There are people who use -1 if they have any comment. There are people who use -1 if they feel patch (the idea, mean and description) should not be submitted. My view is that among the -2, -1, 0, +1, +2 there is a proper room for 0, 0 is a number just like any other number, removing it from scale means narrowing the scale. My personal view is that: 0 - discussion taking place (initial state). +1 - approved for submission by reviewer. +2 - approve for submission by maintainer. -1 - either the change (principal) is rejected, or the patch is so bad that need a major rework, or contributor is not cooperating. -2 - final rejection by maintainer. But this is only my view... BTW: it works fine at engine patches... all discussion takes place at '0' until a decision of -1 or +1 and then final decision of -2 or +2. Regards, Alon. FWIW, all marks are reset when a patch is rebased. This does /not/ mean we can ignore patch history (unless technical issues such as Jenkins). As for the meaning of the numbers this is my general policy for all projects, which I know many maintainers share. Alon's view is close in some points; (-2) This change is either: - Malicious, Illegal or in some other violation - Breaks compilation, build or design That's it. This grade is blunt. Do not use it for any other case. (-1) Any other case where you need to block the patch. (0) Any comment you wish to add. This may include questions and suggestions. Use this and do not block the change if there's no *real* reason to block it. (1) The patch works, but... - I cannot assure it correctness system-wide. - I'd like to reserve what I'm +1-ing for by adding a general comment (e.g. +1 for style, did not review correctness) - Or Flow looks good to me, unsure about style - Or Looks correct but risky so needs second opinion (note that in storage the norm is to have at least 2 reviewers ack before merging). I agree with most but not with this one... Keep in mind that +1 is available for all people while +2 is not. So you cannot abuse +1 for conceptual notes. +1 should be a statement like: Had I been the maintainer I would have submitted
Re: [vdsm] Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all'
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Doron Fediuck dfedi...@redhat.com, Mark Wu wu...@linux.vnet.ibm.com, Greg Padgett gpadg...@redhat.com, vdsm-devel@lists.fedorahosted.org, Ryan Harper ry...@us.ibm.com, Ayal Baron aba...@redhat.com Sent: Tuesday, October 2, 2012 3:26:31 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' On Tue, Oct 02, 2012 at 08:59:05AM -0400, Alon Bar-Lev wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, vdsm-devel@lists.fedorahosted.org, Ryan Harper ry...@us.ibm.com, Ayal Baron aba...@redhat.com Sent: Tuesday, October 2, 2012 2:28:07 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Ryan Harper ry...@us.ibm.com Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron Fediuck dfedi...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, October 1, 2012 10:53:31 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' - Original Message - From: Ryan Harper ry...@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron Fediuck dfedi...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Monday, October 1, 2012 10:24:08 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' * Alon Bar-Lev alo...@redhat.com [2012-09-27 13:38]: Alon Bar-Lev has posted comments on this change. Change subject: Use 'yum clean expire-cache' instead of 'yum clean all' .. Patch Set 2: Ok... I was discussing... I think that if you don't get +1 from parties you should wait... :) I see -1 as final decision... for the entire change... or if contributer is not cooperating. I'm interested in a little clarity here. As I see it, -1 means you don't want the current version submitted. I like the idea of putting a patch on hold while various issues are discussed, and it seems like a -1 is the right idea here since the submitter can reply and original reviewer can re-review and remove a -1 if the submitter has fully explained the issue. Additionaly the submitter can resubmit with changes (and the -1 is removed anyhow). This is exactly the problem... you cannot rely on -1 as it clears if a new patchset is pushed. At the moment, the job of the maintainer cannot be done by a script. The maintainer has to review former opinions on the patch, and check if they have been addressed. If a valuable reviewer gave an opinionated -1, and it was not addressed in a later version, the mainatainer should not take the patch. To me, -1 means: hey, Dan, please do not take this patch into master before we get an answer to my worries, unless there is a more urgent reason to take the patch earlier. Hi Dan, I don't understand why you don't treat 0 at the above... If there were no worries, +1 had been provided... Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all'
- Original Message - From: Ryan Harper ry...@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Mark Wu wu...@linux.vnet.ibm.com, Dan Kenigsberg dan...@redhat.com, Greg Padgett gpadg...@redhat.com, Doron Fediuck dfedi...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Monday, October 1, 2012 10:24:08 PM Subject: Re: Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all' * Alon Bar-Lev alo...@redhat.com [2012-09-27 13:38]: Alon Bar-Lev has posted comments on this change. Change subject: Use 'yum clean expire-cache' instead of 'yum clean all' .. Patch Set 2: Ok... I was discussing... I think that if you don't get +1 from parties you should wait... :) I see -1 as final decision... for the entire change... or if contributer is not cooperating. I'm interested in a little clarity here. As I see it, -1 means you don't want the current version submitted. I like the idea of putting a patch on hold while various issues are discussed, and it seems like a -1 is the right idea here since the submitter can reply and original reviewer can re-review and remove a -1 if the submitter has fully explained the issue. Additionaly the submitter can resubmit with changes (and the -1 is removed anyhow). This is exactly the problem... you cannot rely on -1 as it clears if a new patchset is pushed. Only +1 is to be considered before merge. What is the maintainer view of how best to use -1? And if we don't use a -1, how does one do the above? I think that this is fairly new to have proper procedure set. There are people who use -1 as labelling of what they reviewed. There are people who use -1 if they have any comment. There are people who use -1 if they feel patch (the idea, mean and description) should not be submitted. My view is that among the -2, -1, 0, +1, +2 there is a proper room for 0, 0 is a number just like any other number, removing it from scale means narrowing the scale. My personal view is that: 0 - discussion taking place (initial state). +1 - approved for submission by reviewer. +2 - approve for submission by maintainer. -1 - either the change (principal) is rejected, or the patch is so bad that need a major rework, or contributor is not cooperating. -2 - final rejection by maintainer. But this is only my view... BTW: it works fine at engine patches... all discussion takes place at '0' until a decision of -1 or +1 and then final decision of -2 or +2. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Q on 'git push' to vdsm gerrit
- Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, September 24, 2012 12:19:19 PM Subject: Re: [vdsm] Q on 'git push' to vdsm gerrit On 09/23/2012 11:59 PM, Alon Bar-Lev wrote: Try to branch and re-push, remove your own commits from master so you won't have future problems. I am not following here. Can you elaborate pls ? I am not a gerrit expert, so may be I am missing something. FYI - I am not doing git push from vdsm master branch, in my local git repo, I have a different branch and pushing my patches to gerrit from that branch, did you mean this ? thanx, deepak So that's is fine. If you push the branch again what message do you get? Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Q on 'git push' to vdsm gerrit
- Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Sunday, September 23, 2012 7:17:18 PM Subject: Re: [vdsm] Q on 'git push' to vdsm gerrit On 09/22/2012 09:01 PM, Alon Bar-Lev wrote: - Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Saturday, September 22, 2012 3:47:24 PM Subject: [vdsm] Q on 'git push' to vdsm gerrit Hi, I got the below error from git push, but my patchset is actually pushed, when i see it gerrit. See change # 6856, patchset 8. git push gerrit.ovirt.org:vdsm HEAD:refs/for/master Counting objects: 36, done. Delta compression using up to 4 threads. Compressing objects: 100% (22/22), done. Writing objects: 100% (22/22), 4.33 KiB, done. Total 22 (delta 18), reused 0 (delta 0) remote: Resolving deltas: 100% (18/18) remote: Processing changes: updated: 2, refs: 1, done To gerrit.ovirt.org:vdsm ! [remote rejected] HEAD - refs/for/master (no changes made) error: failed to push some refs to 'gerrit.ovirt.org:vdsm' Background: 1) I was asked to split patchset 7 into multiple patches, rebase and post patchset 8 2) So as part of patchset 8, i had to git pull, rebase and post it via git push ( keep the same ChangeID), which is when I see the above error. 3) But patchset 8 is visible in change 6856, so not sure if I need to be concerned abt the above error ? What does it mean then ? 3a) If you see patchset 8, the dependency is empty, is it because the prev patchset 7 was having a different dep. than 8 ? 3b) But as part of 'parent' i see the reference to the dep. patch. Question 1) Is this the right way to do a git push ? 2) Do i need to be concerned abt the git push error or I can ignore it ? 3) Dependency for patchset 8 in gerrit is empty, tho' parent shows reference to the dep. patch..is this ok, if not, what is the right procedure to follow here ? thanx, deepak It should work without any error. Hmm, I do see the error tho' as above. If you are to submit a patch series (several patches that depend on each other), you should have a branch based on master, and your 8 commits, each with its own unique Change-Id. When pushing this branch you should see each commit depend on previous commit. I am seeing each commit dep on the prev commit for all the patches except the topmost, in gerrit. Not sure why. I agree, i should have probably started a new topic, but i forgot, hence continued to post on master itself. Try to branch and re-push, remove your own commits from master so you won't have future problems. Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Why do we need clean yum cache during bootstrap?
Adding Doron, I found one reason - if local repository files are updated, and hashes needs to be re-generated. Alon - Original Message - From: Mark Wu wu...@linux.vnet.ibm.com To: Douglas Schilling Landgraf dougsl...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, September 21, 2012 11:41:57 AM Subject: [vdsm] Why do we need clean yum cache during bootstrap? Hi Douglas, Why do we need clean yum cache before installing packages during host installation? It could cause a ssh timeout somtimes. On my test VM, it needs several minutes do download yum metatada. Please see the test below: [root@host1 tmp]# time yum update qemu-kvm Loaded plugins: langpacks, presto, refresh-packagekit fedora/metalink | 8.6 kB 00:00 fedora | 4.2 kB 00:00 fedora/primary_db | 14 MB 00:11 fedora/group_gz | 434 kB 00:00 ovirt-nightly | 1.3 kB 00:00 ovirt-nightly/primary | 31 kB 00:00 ovirt-stable | 1.3 kB 00:00 ovirt-stable/primary | 15 kB 00:00 updates/metalink | 4.6 kB 00:00 updates | 4.7 kB 00:00 updates/primary_db | 5.9 MB 03:28 updates/group_gz | 434 kB 00:21 ovirt-nightly 183/183 ovirt-stable 69/69 No Packages marked for Update real4m33.527s user0m5.741s sys0m0.772s [root@host1 tmp]# time yum update qemu-kvm Loaded plugins: langpacks, presto, refresh-packagekit No Packages marked for Update real0m1.184s user0m1.048s sys0m0.115s Thanks! Mark ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:38:23 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 12:12:28 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:06:53 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Itzik Brown itz...@mellanox.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 4:18:08 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Itzik Brown itz...@mellanox.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 5:12:28 PM Subject: [vdsm] Problem building vdsm RPM I'm trying to build vdsm from git . After make rpm I get these errors: snip How exactly do you try to build? This is what working for me: $ git clone ... $ cd vdsm $ autoreconf -ivf $ ./configure $ make dist $ rpmbuild -tb vdsm*.gz The suggested way of building vdsm is: (clone and cd vdsm) $ ./autogen.sh --system $ make rpm No reason for the --system, as rpmbuild will execute configure with right settings. Correct, but since you have to run it why keeping different (wrong) settings locally (vs. the ones that you'll be using in the rpm)? Also, in most projects autogen does not run configure... this is something unique in vdsm I like to avoid. Taken from libvirt, I don't see value in de-automating things. If there is a problem with rpmbuild -tb tarball, we need to fix it... is there any? The problem with your rpmbuild command is that it's not automatic enough, if you want to automate it you use wildcards (vdsm*.gz) which will build any vdsm tar.gz you find in the directory rather the one you just prepared (which is what make rpm is doing). It's not that what you're saying is wrong (after all it's what autogen.sh and the Makefile rely upon, and it works for you), it's that what you do manually is already done automatically (with less potential errors and confusion for the newcomers). Well, my view is that there is a standard method of creating rpms out of source tree. Newcomers that have done this on one project can reuse their knowledge to do this in another project. There is no need to create custom unique methods to confuse people. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Itzik Brown itz...@mellanox.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 5:12:28 PM Subject: [vdsm] Problem building vdsm RPM I'm trying to build vdsm from git . After make rpm I get these errors: snip How exactly do you try to build? This is what working for me: $ git clone ... $ cd vdsm $ autoreconf -ivf $ ./configure $ make dist $ rpmbuild -tb vdsm*.gz Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Adam Litke a...@us.ibm.com Sent: Monday, September 10, 2012 9:41:14 PM Subject: Re: [vdsm] Patch review process * Alon Bar-Lev alo...@redhat.com [2012-09-10 12:44]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Adam Litke a...@us.ibm.com Sent: Monday, September 10, 2012 8:33:53 PM Subject: Re: [vdsm] Patch review process * Alon Bar-Lev alo...@redhat.com [2012-09-10 12:22]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Adam Litke a...@us.ibm.com Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 10, 2012 7:07:56 PM Subject: Re: [vdsm] Patch review process * Adam Litke a...@us.ibm.com [2012-09-09 12:29]: snip I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. Why won't you subscribe to vdsm-patches[1] and comment within gerrit? I am subscribed. Commenting within gerrit is much slower for myself. I'm always in my email client, so sending an email back involves far less work for myself and I don't have to write lots of words in a small text box without a proper text editor. Gerrit comment workflow: 1) follow link from vdsm-patches email to gerrit patch in browser 2) sign-in via openid 3) find which patch file I want to comment upon 4) select the line I want to comment upon to bring up text widget 5) write up comment in a browswer gui box without any support from text editor 6) repeat (3-5) if there are multiple files touched 7) go back to top 8) hit publish Email comment workflow after we know have inline patches. 1) Reply to email 2) find lines in email for comments 3) write up responses in editor 4) close file and mail. This method is superior as the past/present/future comments and review I disagree here. process is managed within productivity application, from birth to merge or death. Much like an email thread with inline patches that's archived for everyone to read and review. Each comment within gerrit is going to the list as if sent directly to the mailing list, so you can track the activity. What's the point of going to the list if not to be able to respond to email? You see the benefit of you as a reviewer, while there are other reviewers (past and future, members and guests) and there is the patch owner. While it may indeed be easier for you to just send a message, for the other people who are involved in the process it may not be as productive as managing the discussion within productivity application which supports the process quite well. Sure; There is a fixed set of folks who already have been working with gerrit for some time and I'm sure are quite comfortable with the process. Part of opening the community up is figuring out how best to attract and maintain additional developers. When growing a community, reducing the barrier for entry is a must. I'll posit that if contributions to gerrit-based communities require the additional openid, web-based commented/editing, some-what undocumented process for obtain review and approval then we're not going to see tremendous growth given the additional overhead of working with gerrit as a contributor. Only recently did we get gerrit to push the code out after submission, meaning that if someone wanted to lurk and read the code, it was always through the web-based viewing; some comments showup on the page of the changeset, the other in-line comments are only available if you know which file the comment was made against. All comments go to the vdsm-patches, but this is a one-way avenue; you don't see discussion happening in response; and if you want to reply, you have to sign-in to gerrit and hunt down the right file. None of this is *bad*; it's just different. Any one of these extra steps could be the excuse that keeps developers from participating. It is not that gerrit is perfect, it is far from being perfect, however has advantages over plain list. I'd really like to hear what advantage
Re: [vdsm] [Engine-devel] is gerrit.ovirt.org down? eom
Yes, I am experiencing this too... Itamar? - Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Shireesh Anjal san...@redhat.com, engine-de...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 12, 2012 5:50:14 PM Subject: Re: [Engine-devel] is gerrit.ovirt.org down? eom It seems gerrit has downed for several times recently. Is there any special reason? 于 2012-9-12 22:45, Alon Bar-Lev: yes. - Original Message - From: Shireesh Anjal san...@redhat.com To: engine-de...@ovirt.org Sent: Wednesday, September 12, 2012 5:43:35 PM Subject: [Engine-devel] is gerrit.ovirt.org down? eom ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Adam Litke a...@us.ibm.com Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Monday, September 10, 2012 7:07:56 PM Subject: Re: [vdsm] Patch review process * Adam Litke a...@us.ibm.com [2012-09-09 12:29]: snip I'm certainly willing to review any patches that show up on the mailing list directly, so if folks want to submit patches first for review before pushing into gerrit; I'm quite happy with reviewing those. Why won't you subscribe to vdsm-patches[1] and comment within gerrit? This method is superior as the past/present/future comments and review process is managed within productivity application, from birth to merge or death. Each comment within gerrit is going to the list as if sent directly to the mailing list, so you can track the activity. Alon. [1] https://lists.fedorahosted.org/pipermail/vdsm-patches/ ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Patch review process
- Original Message - From: Adam Litke a...@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Ryan Harper ry...@linux.vnet.ibm.com, Anthony Liguori aligu...@linux.vnet.ibm.com Sent: Sunday, September 9, 2012 8:27:30 PM Subject: [vdsm] Patch review process While discussing gerrit recently, I learned that some people use gerrit simply to host work-in-progress patches and they don't intend for those to be reviewed. How can a reviewer recognize this and skip those patches when choosing what to review? Is there a way to mark certain patches as more important and others as drafts? Yes. See [1]. $ git push upstream HEAD:refs/drafts/master/description [1] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:36:10 PM Subject: Re: [vdsm] [RFC] Implied UUIDs in API On 08/31/2012 11:27 AM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:23:38 PM Subject: Re: [vdsm] [RFC] Implied UUIDs in API On 08/31/2012 12:33 AM, Alon Bar-Lev wrote: - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:19:46 AM Subject: [vdsm] [RFC] Implied UUIDs in API Hi, in the API a lot of IDs get passed around are UUIDs. The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you. I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs. It's another restriction we can remove from the interface simplifying the code and the interface. Just to be clear I'm not saying that we should stop using UUIDs. For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value. If for some reason we choose to change the format of task IDs. There will be no need to change the interface. The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values. I agree that UUID is just a method of generating unique strings, there is no reason to validate the value nor the format. I'm with daniel on this one - knowing a field is a uuid makes it easier to deal with in the db and code around it compared to a string (stored binary instead of string representation, etc.) Why to store binary? An UUID stored in its binary format takes 16 bytes. Stored as an string it takes 36 bytes, and more than 72 bytes in memory in the engine. The amount of CPU needed to create/compare/etc is proportional. The engine takes advantage of this and uses an specialized UUID class and a specialized database type to manage them. If we change to arbitrary strings then a *lot* of changes have to be done to the engine. We are trying to reduce types of vdsm to simplify the VDSM-next API. I guess it will derive a lot of changes in the engine anyway... 32-72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense. I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 4:22:14 PM Subject: Re: [vdsm] [RFC] Implied UUIDs in API On 08/31/2012 03:36 PM, Alon Bar-Lev wrote: - Original Message - From: Juan Hernandez jhern...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:36:10 PM Subject: Re: [vdsm] [RFC] Implied UUIDs in API On 08/31/2012 11:27 AM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:23:38 PM Subject: Re: [vdsm] [RFC] Implied UUIDs in API On 08/31/2012 12:33 AM, Alon Bar-Lev wrote: - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:19:46 AM Subject: [vdsm] [RFC] Implied UUIDs in API Hi, in the API a lot of IDs get passed around are UUIDs. The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you. I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs. It's another restriction we can remove from the interface simplifying the code and the interface. Just to be clear I'm not saying that we should stop using UUIDs. For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value. If for some reason we choose to change the format of task IDs. There will be no need to change the interface. The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values. I agree that UUID is just a method of generating unique strings, there is no reason to validate the value nor the format. I'm with daniel on this one - knowing a field is a uuid makes it easier to deal with in the db and code around it compared to a string (stored binary instead of string representation, etc.) Why to store binary? An UUID stored in its binary format takes 16 bytes. Stored as an string it takes 36 bytes, and more than 72 bytes in memory in the engine. The amount of CPU needed to create/compare/etc is proportional. The engine takes advantage of this and uses an specialized UUID class and a specialized database type to manage them. If we change to arbitrary strings then a *lot* of changes have to be done to the engine. We are trying to reduce types of vdsm to simplify the VDSM-next API. I guess it will derive a lot of changes in the engine anyway... 32-72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense. that doesn't mean you should abuse it. it's not a single item. its all the items. I guess you want me to analyse our current implementation and find optimizations that can be done... or in different words, find entities we abuse now... :) I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade. Regards, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
- Original Message - From: Saggi Mizrahi smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 31, 2012 12:19:46 AM Subject: [vdsm] [RFC] Implied UUIDs in API Hi, in the API a lot of IDs get passed around are UUIDs. The point is that as long as you are not the entity generating the UUIDs the fact that these are UUIDs have no real significance to you. I suggest removing the validation of UUIDs from the receiving end. There is no real reason to make sure these are real UUIDs. It's another restriction we can remove from the interface simplifying the code and the interface. Just to be clear I'm not saying that we should stop using UUIDs. For example, vdsm will keep generating task IDs as UUIDs. But the documentation will state that it could be *any* string value. If for some reason we choose to change the format of task IDs. There will be no need to change the interface. The same goes for VM IDs. Currently the engine uses UUIDs but there is no reason for VDSM to enforce this and limit the engine from ever changing it in the future and using other string values. I agree that UUID is just a method of generating unique strings, there is no reason to validate the value nor the format. Thanks, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] empty vdsm cert files
Hi,
The boostrap_complete log is required... :)
Anyway, at latest master I rewrote the whole sequence, so it should be good now
(I hope).
Thanks,
Alon.
- Original Message -
From: Ryan Harper ry...@us.ibm.com
To: vdsm-devel@lists.fedorahosted.org
Sent: Tuesday, August 21, 2012 6:56:26 PM
Subject: [vdsm] empty vdsm cert files
[root@ichigo-dom225 vdsm]# find . -type f| xargs -i ls -al {}
-r--r--r--. 1 vdsm kvm 0 Aug 20 14:49 ./certs/cacert.pem
-r--r--r--. 1 vdsm kvm 0 Aug 20 14:49 ./certs/vdsmcert.pem
-rw---. 1 vdsm kvm 11 Aug 17 09:49 ./keys/libvirt_password
-r--r-. 1 vdsm qemu 0 Aug 20 14:49 ./keys/dh.pem
-r--r-. 1 vdsm qemu 0 Aug 20 14:49 ./keys/vdsmkey.pem
Anyone seen this problem?
host has:
[root@ichigo-dom225 tmp]# rpm -qa | grep vdsm
vdsm-python-4.10.0-7.fc17.x86_64
vdsm-4.10.0-7.fc17.x86_64
vdsm-cli-4.10.0-7.fc17.noarch
vdsm-xmlrpc-4.10.0-7.fc17.noarch
Install driven from engine (3.1 release) at this level:
[root@ichigo-dom223 ~]# rpm -qa | grep ovirt-engine
ovirt-engine-userportal-3.1.0-2.fc17.noarch
ovirt-engine-webadmin-portal-3.1.0-2.fc17.noarch
ovirt-engine-sdk-3.1.0.4-1.fc17.noarch
ovirt-engine-setup-3.1.0-2.fc17.noarch
ovirt-engine-restapi-3.1.0-2.fc17.noarch
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-engine-backend-3.1.0-2.fc17.noarch
ovirt-engine-config-3.1.0-2.fc17.noarch
ovirt-engine-genericapi-3.1.0-2.fc17.noarch
ovirt-engine-tools-common-3.1.0-2.fc17.noarch
ovirt-engine-dbscripts-3.1.0-2.fc17.noarch
ovirt-engine-notification-service-3.1.0-2.fc17.noarch
Attaching the vds bootstrap.log ... I don't see anything broken in
here (that I
can tell).
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] empty vdsm cert files
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, August 23, 2012 4:49:00 PM Subject: Re: [vdsm] empty vdsm cert files * Alon Bar-Lev alo...@redhat.com [2012-08-23 04:28]: Hi, The boostrap_complete log is required... :) There was none. I've seen a form of this before[1] where the keys don't get generated (in this case it was that they were empty) and it was as if the completion part wasn't never run. 1. http://lists.ovirt.org/pipermail/users/2012-July/003136.html Anyway, at latest master I rewrote the whole sequence, so it should be good now (I hope). Re-installing worked so I don't yet know how to recreate the issue. Understood. I will love to see the new implementation in action and fix whatever issue that may raise. Thank you, alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] empty vdsm cert files
- Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, August 23, 2012 7:59:53 PM Subject: Re: [vdsm] empty vdsm cert files * Alon Bar-Lev alo...@redhat.com [2012-08-23 11:04]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, August 23, 2012 5:13:43 PM Subject: Re: [vdsm] empty vdsm cert files * Alon Bar-Lev alo...@redhat.com [2012-08-23 09:02]: - Original Message - From: Ryan Harper ry...@us.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: Ryan Harper ry...@us.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, August 23, 2012 4:49:00 PM Subject: Re: [vdsm] empty vdsm cert files * Alon Bar-Lev alo...@redhat.com [2012-08-23 04:28]: Hi, The boostrap_complete log is required... :) There was none. I've seen a form of this before[1] where the keys don't get generated (in this case it was that they were empty) and it was as if the completion part wasn't never run. 1. http://lists.ovirt.org/pipermail/users/2012-July/003136.html Anyway, at latest master I rewrote the whole sequence, so it should be good now (I hope). Re-installing worked so I don't yet know how to recreate the issue. Understood. I will love to see the new implementation in action and fix whatever issue that may raise. Are there rpms with the new code? I can test out a fresh deployment on F17 and see how that goes? Hi, I see the latest nightly builds[1] are post change. BTW: You can always build your own rpms.. Sure, I was hoping for a matched pair. I need both newer vdsm and engine to test? Basically, you need latest vdsm only for vdsm-bootstrap package installed at the engine side. You can use whatever vdsm you like at the node side (your current one is OK). Or to make it simpler use latest and be done :) Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
