Request for include python-ethtool-0.8.1

[Mike Burns]

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.


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


[1] http://gerrit.ovirt.org/16125