Description of problem: In RHV-H environment, OVN 'ovirt-provider-ovn-driver' package is not installed, and should be installed by default in order to use the OVN feature. Version-Release number of selected component (if applicable): Red Hat Virtualization Manager Version: 4.1.6.1-0.1.el7 How reproducible: 100% Steps to Reproduce: 1. rpm -qa | grep ovirt-provider-ovn Actual results: Not installed. Expected results: Should be installed.
Ryan, what should we do to include ovirt-provider-ovn in the ovirt-node default content?
Is this actually something we want as default for 4.2? If it is, we can just bake it into the image. If not, we can whitelist upstream and ship in the rhvh channel downstream.
Yes, I would like this package to be baked into the default image, even though OVN is only on tech-preview in 4.1.
Ryan, can you point us to the list of packages included in the image?
This can (basically) be discovered by "rpm -q -requires ovirt-release-host-node|redhat-release-virtualization-host". Anything else pulled in via depsolving See https://gerrit.ovirt.org/gitweb?p=ovirt-release.git;a=blob;f=ovirt-release-master.spec.in;h=b9fa2b2aa3423f0f9852a0aecd4de397caac7522;hb=HEAD#l49 If you want a complete list, I can get one. However, as with many other "please include in node..." bugs, I'd suggest that if this is going to be a default in 4.2, some other package should require it, which helps keep RHVH and RHELH consistent. ovirt-host is probably a good bet for 4.2
I prefer to be able to install plain RHEL-H without the baggage of openvswitch and ovn, even though they are going to be the default in 4.2 RHEL-H is all about tweaking a mixing a choosing. On RHV-H, customers do not have this flexibility. ovirt-node does not have the yum repositories configured, so the (default) deployment of ovirt-provider-ovn-driver would fail if it is not already on the node.
While I agree that the virtue of RHEL-H is flexibility, the point of the ovirt-host package in 4.2 (not Node) is to reduce the potentially confusing hodgepodge of packages which must be kept track of, both for host-deploy and RHVH. In this sense, it makes much more sense to me to put defaults there, and let users who want to customize follow another pattern. Sandro, thoughts?
Is the OVN feature supposed to be enabled by default in 4.2? If it has to be enabled by default, please add ovirt-provider-ovn-driver to ovirt-host package dependencies so it will be installed by default on both on oVirt Node and on common hosts. Please note that this is an RFE and that a backport to 4.1 will require changes in ovirt-hosted-engine-setup, ovirt-host-deploy and ovirt-engine instead of a single change in ovirt-host package. Targeting to 4.2 for now.
As a part of ovirt-provider-ovn-driver Ansible role [1], you are installing ovirt-provider-ovn-driver, ovn-controller and openvswitch packages. Is there any issue with those packages being installed by default without being them configured? If not, then it makes sense to add them as a dependency to ovirt-host package [3] and inside Ansible role [1] just configure them as needed. Dan/Dominik? [1] https://github.com/oVirt/ovirt-ansible/pull/73 [2] https://github.com/oVirt/ovirt-ansible/pull/73/files#diff-9436c91d0e52294460adf3592556b3ec [3] https://gerrit.ovirt.org/#/admin/projects/ovirt-host
It should be possible, like it is now, to use oVirt without being forced to use or even install OpenVSwitch. Ideally this is controlled by the inputs of engine-setup. This is explained here in this commit message [1], too: > OVN integration is an important feature of oVirt-4.2, so we need to ship > ovirt-provider-ovn-driver in the node image. We place the dependency > directly here and not in ovirt-host, because we would like to allow the > flexibility of deploying oVirt without the baggage of OpenVSwitch. [1] https://gerrit.ovirt.org/#/c/81479/2//COMMIT_MSG
Right, but is this a default or not? Even if it's not enabled by default, it seems that it should be installed...
Yes, it is going to be on by default. On ovirt-node it *has* to be pre-installed, but I still hope users can opt-out of installing ovs on each of their hosts when it comes to RHEL-H. I don't like the rigidness of ovirt-host. I hope that one day, users can mix and match, and install an ovirt host without nfs, or without iscsi, or without ovs, if they do not need the functionality. Still, I think that the discussion moves in small circles. I'd like to have ovirt-provider-ovn-driver in ovirt-node, but not in ovirt-host. If you think it is stupid/wrong/countereffective, just give me a polite -2 on my patch, and we'll do what you say and put it in ovirt-host.
I'm definitely ok with having this in Node, I just want to make sure that we're not duplicating effort here. We try very hard not to include individual packages by name in NGN. That's ok. I just don't know whether mix-and-match will be in 3.2 or not, as much as it's a goal
We *are* putting more effort in order to make RHEL-H more lightweight and less rigid. There's nothing else I can say about the subject. If you don't want my suggested named package in NGN, just give it a -2, and I'll move it to ovirt-host.
Don't get me wrong -- we'll happily take the patch. I just want to make sure we're not going to track it in two places. If ovirt-host picks it up, we'll drop it. Otherwise, we're very happy to have the contribution
OK, based on above discussion I've just acked https://github.com/oVirt/ovirt-ansible/pull/73
Ryan, Sandro: I prefer that you take the dependency into the node http://gerrit.ovirt.org/81479 but if you feel that placing it in ovirt-host please take http://gerrit.ovirt.org/81615
Verified that ovirt-node-ng-4.2.0-0.20170918.0+1 contains: ovirt-provider-ovn-driver-1.1-2.20170913111304.git409ae9a.el7.centos.noarch package.
*** Bug 1519124 has been marked as a duplicate of this bug. ***
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.