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.