[Users] Low quality of el6 vdsm rpms
Hi all, sorry for this rant, but... I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times. One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago): /usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent - How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms. - How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree... Thx and Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
Regarding the pep8 breakage - Try updating your pep8. ----- Original Message ----- From: "Patrick Hurrelmann" <patrick.hurrelmann@lobster.de> To: "oVirt Mailing List" <users@ovirt.org> Sent: Tuesday, November 12, 2013 11:34:20 AM Subject: [Users] Low quality of el6 vdsm rpms Hi all, sorry for this rant, but... I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times. One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago): /usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent - How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms. - How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree... Thx and Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12.11.2013 11:07, Assaf Muller wrote:
Regarding the pep8 breakage - Try updating your pep8.
Hi, thanks for the hint, but according to http://www.ovirt.org/Vdsm_Developers the latest python-pep8 (python-pep8-1.3.3-3.el6) for el6 is already installed. And further digging shows that probably http://gerrit.ovirt.org/#/c/21055/ was not yet merged to 3.3. Regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms. - How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Since this is VDSM related, adding vdsm-devel list to the discussion.
Thx and Regards Patrick
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Hey Patrick, For the pep8 issue, as mentioned you should check pep8 --version and use 1.4.6. If you use older version, just upgrade with python-pip (yum install python-pip , and then `pip-install install pep8 --upgrade`) Second, try to follow http://www.ovirt.org/Vdsm_Developers , it specifies the repositories you need to set (which should solve and selinux-policy package you miss) and should be the same for ovirt-3.3. About the hostname issue, can you detail more about the issue .. I'm not familiar with such error There are some differences between ovirt-3.3 branch and master in the requirements scope, each with specific reason. you should checkout ovirt-3.3 branch and not ovirt-3.3.0 for those tests We are working on the quality and constantly trying to increase and improve the software. About the builds process you can talk with eedri for more details Regards, Yaniv Bronhaim. ----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "patrick hurrelmann" <patrick.hurrelmann@lobster.de>, "oVirt Mailing List" <users@ovirt.org>, "vdsm-devel" <vdsm-devel@fedorahosted.org> Sent: Tuesday, November 12, 2013 12:31:04 PM Subject: Re: [vdsm] [Users] Low quality of el6 vdsm rpms
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms. - How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Since this is VDSM related, adding vdsm-devel list to the discussion.
Thx and Regards Patrick
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are: - Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545 - There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days? - Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available. Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
- How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Based on your reports, you are tracking the correct tree; but please describe which differences do you see (and between what releases exactly). Regards, Dan.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, dcaro@redhat.com Cc: "vdsm-devel" <vdsm-devel@fedorahosted.org>, "oVirt Mailing List" <users@ovirt.org> Sent: Tuesday, November 12, 2013 4:33:44 PM Subject: Re: [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago):
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
- How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms.
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are: - Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
- There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
it does run, but we can't enable it since it's still failing: http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/label=fedora... once that's fixed, the job will be enabled and run per patch.
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
- How are the builds prepared? Is there a Jenkins job that prepares "stable" rpms in addition to the nightly job? Or is this totally handcrafted?
no jenkins job for stable builds. just nightly builds published from this job which build only rpms from master. http://jenkins.ovirt.org/view/Packaging/job/vdsm_create_rpms/
- How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree...
Based on your reports, you are tracking the correct tree; but please describe which differences do you see (and between what releases exactly).
Regards, Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote:
<snip>
- There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
it does run, but we can't enable it since it's still failing: http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/label=fedora...
once that's fixed, the job will be enabled and run per patch.
Yaniv, any idea why we still have file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of vdsm-python-cpopen-4.12.1-4.fc19.x86_64 conflicts with file from package python-cpopen-1.2.3-2.fc19.x86_64 ?
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful. Dan.
On Tue, Nov 12, 2013 at 04:41:53PM +0000, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote:
<snip>
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade.
Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful.
A concerned user just asked me how did I build this. I just took the source from koji, http://kojipkgs.fedoraproject.org//packages/python-pep8/1.4.5/2.fc20/src/pyt... and built it on an el6 host with http://kojipkgs.fedoraproject.org//packages/python-sphinx/1.0.8/1.el6/noarch... installed. Dan.
On 12.11.2013 15:33, Dan Kenigsberg wrote:
I suspect you are not interested in "excuses" for each of the failures, let us look forwards. My conclusions are: - Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545
- There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days?
- Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available.
Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again)
Yes, exactly. It wasn't my intention to blame anyone. I just wanted to express how hard it can be to test and show up some points for future work ;) I'm looking forward to the recent QA plans. There has been an impressive overall improvement in the project over the last year, but there is still room for improvement. Thanks all. Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
Hi Patrick, On 11/12/2013 09:33 AM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from?
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build. We would appreciate if you could continue the tests with the new test build: F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612 This last update includes the following patches: - The require hostname fix - upgrade-fix-v3ResetMetaVolSize-argument - lvm-Do-not-use-udev-cache-for-obtaining-device-list - Fix-ballooning-rules-for-computing-the-minimum-avail - Avoid-M2Crypto-races - spec-declare-we-provide-an-existing-python-cpopen - configuring-selinux-allowing-qemu-kvm-to-generate-co @Mike, can you please update the testing candidate repo? Thanks! -- Cheers Douglas
On 11/12/2013 03:51 PM, Douglas Schilling Landgraf wrote:
Hi Patrick,
On 11/12/2013 09:33 AM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised.
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires "hostname" instead of "/bin/hostname". This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from?
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches: - The require hostname fix - upgrade-fix-v3ResetMetaVolSize-argument - lvm-Do-not-use-udev-cache-for-obtaining-device-list - Fix-ballooning-rules-for-computing-the-minimum-avail - Avoid-M2Crypto-races - spec-declare-we-provide-an-existing-python-cpopen - configuring-selinux-allowing-qemu-kvm-to-generate-co
@Mike, can you please update the testing candidate repo?
Packages updated in beta repo
Thanks!
On 12.11.2013 19:15, Mike Burns wrote:
On 11/12/2013 03:51 PM, Douglas Schilling Landgraf wrote:
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches: - The require hostname fix - upgrade-fix-v3ResetMetaVolSize-argument - lvm-Do-not-use-udev-cache-for-obtaining-device-list - Fix-ballooning-rules-for-computing-the-minimum-avail - Avoid-M2Crypto-races - spec-declare-we-provide-an-existing-python-cpopen - configuring-selinux-allowing-qemu-kvm-to-generate-co
@Mike, can you please update the testing candidate repo?
Packages updated in beta repo
Thanks for the new builds. I will try them tomorrow. Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
On Tue, Nov 12, 2013 at 03:51:36PM -0500, Douglas Schilling Landgraf wrote:
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches: - The require hostname fix
(http://gerrit.ovirt.org/#/c/21194/ should have been sent to gerrit long ago, I suppose)
On 11/12/2013 04:52 PM, Dan Kenigsberg wrote:
On Tue, Nov 12, 2013 at 03:51:36PM -0500, Douglas Schilling Landgraf wrote:
Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build.
We would appreciate if you could continue the tests with the new test build:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612
This last update includes the following patches: - The require hostname fix
(http://gerrit.ovirt.org/#/c/21194/ should have been sent to gerrit long ago, I suppose)
Not really, actually, http://permalink.gmane.org/gmane.linux.redhat.fedora.extras.cvs/1127350 shouldn't be included in the previous build and it was during the spec merge from fedora spec, 4.12.0 and 4.13.0 for 3.3, my bad. I did a new build on rawhide right now and the workaround is not needed anymore. I have back the original /bin/hostname for rawhide (as I did above). We should be fine with vdsm-4.13.0-11 or higher. -- Cheers Douglas
Hi, can someone elaborate on this fix? Is something broken with the ballooning-rules in the current vdsm? If yes, what is it, and can it be circumvented until a new vdsm stable release hits the ovirt.org repo? Thanks in advance! Am 12.11.2013 21:51, schrieb Douglas Schilling Landgraf:
- Fix-ballooning-rules-for-computing-the-minimum-avail
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Hello Sven, On 11/13/2013 03:39 AM, Sven Kieske wrote:
Hi,
can someone elaborate on this fix?
Sure. The report it available at: https://bugzilla.redhat.com/show_bug.cgi?id=1025845 commit c62a6904bff7c2657cf4f184346e32916f90a2c7 Author: Martin Sivak <msivak@redhat.com> Date: Mon Nov 4 10:53:07 2013 +0100 Fix ballooning rules for computing the minimum available memory Change-Id: Ie416db6580462bbd16e80bea0a4e339656eccb0f Reviewed-on: http://gerrit.ovirt.org/20849/ Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1025845 Signed-off-by: Martin Sivak <msivak@redhat.com> Reviewed-on: http://gerrit.ovirt.org/20906 Reviewed-by: Yaniv Bronhaim <ybronhei@redhat.com>
Is something broken with the ballooning-rules in the current vdsm? If yes, what is it, and can it be circumvented until a new vdsm stable release hits the ovirt.org repo?
Thanks in advance!
Am 12.11.2013 21:51, schrieb Douglas Schilling Landgraf:
- Fix-ballooning-rules-for-computing-the-minimum-avail
-- Cheers Douglas
Hi, is there any chance that the fixes for this bug get into 3.3.x or at least 3.4 ? I see no targeted Milestone for it, and this is something I would consider a core feature, which should "just work". Am 14.11.2013 21:35, schrieb Douglas Schilling Landgraf:
Hello Sven,
On 11/13/2013 03:39 AM, Sven Kieske wrote:
Hi,
can someone elaborate on this fix?
Sure. The report it available at: https://bugzilla.redhat.com/show_bug.cgi?id=1025845
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Hi Sven, On 11/15/2013 05:42 AM, Sven Kieske wrote:
Hi,
is there any chance that the fixes for this bug get into 3.3.x or at least 3.4 ? I see no targeted Milestone for it, and this is something I would consider a core feature, which should "just work".
It's targeted for 3.3.1 and it shows in release notes for VDSM: http://www.ovirt.org/OVirt_3.3.1_release_notes -- Cheers Douglas
Ah, thanks for the hint, the "fixed bugs" list is quite long, so I didn't read everything, I will give this some testing if it is already in 3.3.1-2 beta (not mentioned in release notes?), but I think it will work, this release seems very stable and focused to me. OT: Why is there no announcement for beta releases on the announcement list? To keep traffic low? The last message is from 16.10.2013 so you shouldn't be feared to "spam" this list (imho). ;) Am 15.11.2013 18:05, schrieb Douglas Schilling Landgraf:
Hi Sven,
On 11/15/2013 05:42 AM, Sven Kieske wrote:
Hi,
is there any chance that the fixes for this bug get into 3.3.x or at least 3.4 ? I see no targeted Milestone for it, and this is something I would consider a core feature, which should "just work".
It's targeted for 3.3.1 and it shows in release notes for VDSM: http://www.ovirt.org/OVirt_3.3.1_release_notes
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Hello Sven, On 11/15/2013 09:35 AM, Sven Kieske wrote:
Ah, thanks for the hint, the "fixed bugs" list is quite long, so I didn't read everything, I will give this some testing if it is already in 3.3.1-2 beta (not mentioned in release notes?), but I think it will work, this release seems very stable and focused to me.
The vdsm package which fix this list of bug is already in the beta.
OT: Why is there no announcement for beta releases on the announcement list? To keep traffic low? The last message is from 16.10.2013 so you shouldn't be feared to "spam" this list (imho). ;)
I do believe the best is raise this question into another e-mail thread ;-) Thanks!
Am 15.11.2013 18:05, schrieb Douglas Schilling Landgraf:
Hi Sven,
On 11/15/2013 05:42 AM, Sven Kieske wrote:
Hi,
is there any chance that the fixes for this bug get into 3.3.x or at least 3.4 ? I see no targeted Milestone for it, and this is something I would consider a core feature, which should "just work".
It's targeted for 3.3.1 and it shows in release notes for VDSM: http://www.ovirt.org/OVirt_3.3.1_release_notes
-- Cheers Douglas
On 12.11.2013 11:31, Sandro Bonazzola wrote:
Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto:
Hi all,
sorry for this rant, but...
I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times.
I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ?
Will do. I just finished migrating an old 3.1 el6 installation to a fresh 3.3.1. -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
----- Original Message -----
From: "Patrick Hurrelmann" <patrick.hurrelmann@lobster.de> To: "oVirt Mailing List" <users@ovirt.org> Sent: Tuesday, November 12, 2013 11:34:20 AM Subject: [Users] Low quality of el6 vdsm rpms
Hi all,
sorry for this rant, but...
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
Fixed in upstream - http://gerrit.ovirt.org/#/c/21055/ Do we need a backport to ovirt-3.3? Nir
Hello Nir, On 11/12/2013 02:27 PM, Nir Soffer wrote:
----- Original Message -----
From: "Patrick Hurrelmann" <patrick.hurrelmann@lobster.de> To: "oVirt Mailing List" <users@ovirt.org> Sent: Tuesday, November 12, 2013 11:34:20 AM Subject: [Users] Low quality of el6 vdsm rpms
Hi all,
sorry for this rant, but...
/usr/bin/pep8 --exclude="config.py,constants.py" --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent
Fixed in upstream - http://gerrit.ovirt.org/#/c/21055/
Do we need a backport to ovirt-3.3?
IMO yes, would be nice to have this patch as well. -- Cheers Douglas
participants (10)
-
Assaf Muller -
Dan Kenigsberg -
Douglas Schilling Landgraf -
Eyal Edri -
Mike Burns -
Nir Soffer -
Patrick Hurrelmann -
Sandro Bonazzola -
Sven Kieske -
Yaniv Bronheim