Request for include python-ethtool-0.8.1

[Dan Kenigsberg]

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/netinfoTests/TestNetinfo/testGetIfaceByIP/
> >
> > 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