
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.