Bug 1544326 - [OVN] - "Default" cluster always returns to default network provider on engine-setup although was set with No default provider
Summary: [OVN] - "Default" cluster always returns to default network provider on engin...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.1.4
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ovirt-4.2.2
: ---
Assignee: Dominik Holler
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-12 07:33 UTC by Michael Burman
Modified: 2018-03-29 11:09 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-29 11:09:07 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.2+
rule-engine: ovirt-4.3+
ylavi: exception+


Attachments (Terms of Use)
Logs (405.66 KB, application/x-gzip)
2018-02-12 07:33 UTC, Michael Burman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 88024 0 master MERGED packaging: setup: ovn: Change condition to modify Default clusters 2018-02-22 15:00:18 UTC
oVirt gerrit 88087 0 ovirt-engine-4.2 MERGED packaging: setup: ovn: Change condition to modify Default clusters 2018-02-26 12:51:57 UTC

Description Michael Burman 2018-02-12 07:33:26 UTC
Created attachment 1394797 [details]
Logs

Description of problem:
[OVN] - Default cluster always returns to default network provider on engine-setup although was set with No default provider.

The default behaviour for the default cluster is to always set ovirt-provider-ovn on engine-setup, although the user/admin has decided that the default cluster will be set with No Default Provider. 

Version-Release number of selected component (if applicable):
4.2.1.6-0.1.el7

How reproducible:
100%

Steps to Reproduce:
1. Run latest RHV 4.2
2. Set the default cluster with Default Network Provider=No Default Provider
3. Run engine-setup

Actual results:
Default cluster return to be set with Default Network Provider=ovirt-provider-ovn

Expected results:
If the admin/user has decided to set the default cluster as No Default Cluster, then on engine-setup we shouldn't return the default network provider for the default cluster.

Comment 1 Dan Kenigsberg 2018-02-14 12:26:22 UTC
After discussing this with Dominik, I recall that this is a known problem in our implementation. The step where ovirt-engine-setup creates the provider and adds it to the Default cluster is independent of the step where the Default cluster is created. It can certainly not know if the Default cluster was already long ago, and the provider was explicitly removed from it. For that, Engine would have to leave a filesystem hint when removing the provider from the cluster.

I don't see a simple way to solve this; a simple workaround for the user is to rename the cluster to something other than "Default".

Comment 2 Michael Burman 2018-02-19 07:10:28 UTC
qe are not OK with closing this report. Will discuss it on the weekly scrub.

Comment 3 Michael Burman 2018-02-19 09:59:21 UTC
Hi Dominik,

During engine-setup, do we aware if it's a clean installation or upgrade?
If we do, then we can touch the default only on clean install and on upgrade to not touch the ovn configuration for the default cluster and this way to handle this issue. 
Renaming the default cluster name is an ugly WA.

Comment 4 Dominik Holler 2018-02-21 10:14:35 UTC
Sounds like a good alternative. I will check this.

Comment 5 Dominik Holler 2018-02-22 13:32:13 UTC
We can touch the clusters with name 'Default' if the ovirt-provider-ovn is configured. This will occur only if the provider is installed the first time, but not on upgrading an existing installation.

Comment 6 Michael Burman 2018-03-06 08:36:20 UTC
Verified on - 4.2.2.2-0.1.el7

Comment 7 Sandro Bonazzola 2018-03-29 11:09:07 UTC
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.