Request for include python-ethtool-0.8.1

Hi, Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories? [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/ Regards, Petr Ĺ ebek.

On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne... AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses' Regards, Dan.

On 06/25/2013 05:12 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne...
AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses'
Regards, Dan.
What about EL6? These packages aren't available in EL6, so how do you handle this issue there? I really don't like hosting packages that are part of a distro but not part of oVirt on ovirt.org, especially ones like libvirt that are core functionality. It's also worth noting that this will have significant impact on oVirt Node which builds with stock Fedora packages. The inclusion of a newer libvirt will require that the base image either include a newer libvirt (unlikely) or that libvirt be updated when installing the plugin (undesired since it's core functionality). I have no objection to installing a newer package on the jenkins slaves. Mike

On Tue, Jun 25, 2013 at 07:30:31AM -0400, Mike Burns wrote:
On 06/25/2013 05:12 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne...
AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses'
Regards, Dan.
What about EL6? These packages aren't available in EL6, so how do you handle this issue there?
Surprisingly, EL6's python-ethtool has provided this functionality before it was available in Fedora. This obviously caused some confusion.
I really don't like hosting packages that are part of a distro but not part of oVirt on ovirt.org, especially ones like libvirt that are core functionality.
I do not think we have much of a choice here, since we have different release cycles than Fedora. Hopefully, one day we would be distro-independent which would make the problem more acute. For example, we where asked to add support for reporting funny NUMA configs in http://gerrit.ovirt.org/11709a . This requires a newer libvirt than Fedora 18 has. We could revert this in ovirt-3.3 for Fedora 18, but I'd rather require a libvirt from Fedora 18 virt-preview http://fedorapeople.org/groups/virt/virt-preview/fedora-18/x86_64/ This would enable us to expose a clean feature set, regardless of the underlying distribution.
It's also worth noting that this will have significant impact on oVirt Node which builds with stock Fedora packages. The inclusion of a newer libvirt will require that the base image either include a newer libvirt (unlikely) or that libvirt be updated when installing the plugin (undesired since it's core functionality).
I understand the problem, but it is unescapable that the fact that ovirt-node is going to be used for things other than ovirt means more work, and more differentiation between ovirt-node-for-ovirt and ovirt-node-for-something-else.
I have no objection to installing a newer package on the jenkins slaves.
Mike

installed on both f18 slaves. e. ----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Mike Burns" <mburns@redhat.com> Cc: "Petr Sebek" <psebek@redhat.com>, "Eyal Edri" <eedri@redhat.com>, infra@ovirt.org Sent: Tuesday, June 25, 2013 4:19:51 PM Subject: Re: Request for include python-ethtool-0.8.1
On Tue, Jun 25, 2013 at 07:30:31AM -0400, Mike Burns wrote:
On 06/25/2013 05:12 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne...
AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses'
Regards, Dan.
What about EL6? These packages aren't available in EL6, so how do you handle this issue there?
Surprisingly, EL6's python-ethtool has provided this functionality before it was available in Fedora. This obviously caused some confusion.
I really don't like hosting packages that are part of a distro but not part of oVirt on ovirt.org, especially ones like libvirt that are core functionality.
I do not think we have much of a choice here, since we have different release cycles than Fedora. Hopefully, one day we would be distro-independent which would make the problem more acute.
For example, we where asked to add support for reporting funny NUMA configs in http://gerrit.ovirt.org/11709a . This requires a newer libvirt than Fedora 18 has. We could revert this in ovirt-3.3 for Fedora 18, but I'd rather require a libvirt from Fedora 18 virt-preview http://fedorapeople.org/groups/virt/virt-preview/fedora-18/x86_64/
This would enable us to expose a clean feature set, regardless of the underlying distribution.
It's also worth noting that this will have significant impact on oVirt Node which builds with stock Fedora packages. The inclusion of a newer libvirt will require that the base image either include a newer libvirt (unlikely) or that libvirt be updated when installing the plugin (undesired since it's core functionality).
I understand the problem, but it is unescapable that the fact that ovirt-node is going to be used for things other than ovirt means more work, and more differentiation between ovirt-node-for-ovirt and ovirt-node-for-something-else.
I have no objection to installing a newer package on the jenkins slaves.
Mike

On 06/25/2013 09:19 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 07:30:31AM -0400, Mike Burns wrote:
On 06/25/2013 05:12 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne...
AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses'
Regards, Dan.
What about EL6? These packages aren't available in EL6, so how do you handle this issue there?
Surprisingly, EL6's python-ethtool has provided this functionality before it was available in Fedora. This obviously caused some confusion.
python-ethtool added to nightly F18 repository. As per today's meeting, libvirt will not be added. Instead, we'll tell people to use the fedora-virt-preview repositories to get updated libvirt rpms. A patch has been submitted to ovirt-release [1] to add this repo definition.
I really don't like hosting packages that are part of a distro but not part of oVirt on ovirt.org, especially ones like libvirt that are core functionality.
I do not think we have much of a choice here, since we have different release cycles than Fedora. Hopefully, one day we would be distro-independent which would make the problem more acute.
For example, we where asked to add support for reporting funny NUMA configs in http://gerrit.ovirt.org/11709a . This requires a newer libvirt than Fedora 18 has. We could revert this in ovirt-3.3 for Fedora 18, but I'd rather require a libvirt from Fedora 18 virt-preview http://fedorapeople.org/groups/virt/virt-preview/fedora-18/x86_64/
This would enable us to expose a clean feature set, regardless of the underlying distribution.
It's also worth noting that this will have significant impact on oVirt Node which builds with stock Fedora packages. The inclusion of a newer libvirt will require that the base image either include a newer libvirt (unlikely) or that libvirt be updated when installing the plugin (undesired since it's core functionality).
I understand the problem, but it is unescapable that the fact that ovirt-node is going to be used for things other than ovirt means more work, and more differentiation between ovirt-node-for-ovirt and ovirt-node-for-something-else.
It was never about the work, it was just a change in a core package that made me nervous. After discussion with the rest of the Node team and checking with some other consumers, we'll include virt-preview packages by default going forward for Fedora based images. There was also concern about the potential size increase for the image with upgrading libvirt. A lot of the minimization is done only on the initial build, not on plugin installation (we're investigating whether we can run it all). the libvirt dependencies bring a lot of packages that can be minimized. Mike
I have no objection to installing a newer package on the jenkins slaves.
Mike

On Wed, Jun 26, 2013 at 11:41:51AM -0400, Mike Burns wrote:
On 06/25/2013 09:19 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 07:30:31AM -0400, Mike Burns wrote:
On 06/25/2013 05:12 AM, Dan Kenigsberg wrote:
On Tue, Jun 25, 2013 at 03:51:47AM -0400, Petr Sebek wrote:
Hi,
Could you please include python-ethtool-0.8.1 rpm [1] to ovirt-3.3 repositories and to [2]. We need this version of python-ethtool because of this patch [3]. Would be also possible to include libvirt>=1.0.1 to this repositories?
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5538273 [2] http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/ [3] http://gerrit.ovirt.org/#/c/11519/
Also, please install this version of python-ethtool on the Fedora slaves that run vdsm unit tests. Until we do, we'd have unit test failures such as in http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/2984/testReport/junit/ne...
AttributeError: 'ethtool.etherinfo' object has no attribute 'get_ipv4_addresses'
Regards, Dan.
What about EL6? These packages aren't available in EL6, so how do you handle this issue there?
Surprisingly, EL6's python-ethtool has provided this functionality before it was available in Fedora. This obviously caused some confusion.
python-ethtool added to nightly F18 repository.
As per today's meeting, libvirt will not be added. Instead, we'll tell people to use the fedora-virt-preview repositories to get updated libvirt rpms. A patch has been submitted to ovirt-release [1] to add this repo definition.
Thanks! <snip>
It's also worth noting that this will have significant impact on oVirt Node which builds with stock Fedora packages. The inclusion of a newer libvirt will require that the base image either include a newer libvirt (unlikely) or that libvirt be updated when installing the plugin (undesired since it's core functionality).
I understand the problem, but it is unescapable that the fact that ovirt-node is going to be used for things other than ovirt means more work, and more differentiation between ovirt-node-for-ovirt and ovirt-node-for-something-else.
It was never about the work, it was just a change in a core package that made me nervous.
Just for the record, I was not implicating that you are afraid of more work. Doubling the support matrix is frightening.
After discussion with the rest of the Node team and checking with some other consumers, we'll include virt-preview packages by default going forward for Fedora based images. There was also concern about the potential size increase for the image with upgrading libvirt. A lot of the minimization is done only on the initial build, not on plugin installation (we're investigating whether we can run it all). the libvirt dependencies bring a lot of packages that can be minimized.
This reminds me of our coarse Requires: libvirt line. I see no reason to pull libvirt-daemon-driver-xen or even libvirt-daemon-driver-storage before ovirt uses them. I suppose that they are blacklisted by ovirt-node, but they are pull by plain Fedora installations. I'd like to solicit review of my patches below. spec: finer-grained libvirt requirement: http://gerrit.ovirt.org/#/c/15760/ http://gerrit.ovirt.org/#/c/15761/ Dan.
participants (4)
-
Dan Kenigsberg
-
Eyal Edri
-
Mike Burns
-
Petr Sebek