Request for include python-ethtool-0.8.1

Dan Kenigsberg danken at redhat.com
Thu Jun 27 09:25:45 UTC 2013


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/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.
> 
> 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.



More information about the Infra mailing list