Bug 1231799

Summary: [RFE] hosted-engine-setup should let its user choose the name of the bridge to be created (and have ovirtmgmt as default)
Product: [oVirt] ovirt-hosted-engine-setup Reporter: Michal Skrivanek <michal.skrivanek>
Component: RFEsAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED WONTFIX QA Contact: Nikolai Sednev <nsednev>
Severity: high Docs Contact:
Priority: low    
Version: 2.0.0CC: bugs, danken, dfediuck, didi, lpeer, lsurette, lveyde, mavital, mburman, michal.skrivanek, mkalinin, myakove, rbalakri, Rhev-m-bugs, sbonazzo, srevivo, stirabos, vfeenstr, ykaul, ylavi
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: ylavi: ovirt-future?
ylavi: planning_ack+
sbonazzo: devel_ack?
ylavi: testing_ack?
Hardware: x86_64   
OS: Linux   
URL: http://www.ovirt.org/Features/Management_Network_As_A_Role
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Feature: hosted-engine-setup should let its user choose the name of the bridge to be created (and have ovirtmgmt as default) Reason: Result:
Story Points: ---
Clone Of: 1204793 Environment:
Last Closed: 2018-06-06 12:27:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 965289, 1204793, 1231836    
Bug Blocks:    

Description Michal Skrivanek 2015-06-15 12:23:45 UTC
as Sandro noted, we need a corresponding change in HE setup

+++ This bug was initially created as a clone of Bug #1204793 +++

Description of problem:
Reduce diff between upstream and downstream management networks, use the same name for new clusters. ovirt-mgmt should be used for both ovirt & RHEV.
Need to make sure we do not change existing networks and only use new name for new clusters.

Comment 1 Dan Kenigsberg 2015-06-15 17:17:01 UTC
*** Bug 1231836 has been marked as a duplicate of this bug. ***

Comment 2 Yaniv Lavi 2015-06-18 10:22:29 UTC
Upgrades should keep the same network name, only change in clean installations.

Comment 3 Sandro Bonazzola 2015-06-18 11:04:07 UTC
(In reply to Yaniv Dary from comment #2)
> Upgrades should keep the same network name, only change in clean
> installations.

ok. I guess we'll have issues deploying new 3.6 hosts to be added to a cluster upgraded from 3.5 but we'll handle with the help of the network team.

Comment 5 Dan Kenigsberg 2015-06-18 13:00:24 UTC
Actually, since 3.6 engine allows the admin to choose whatever name for his management network (http://www.ovirt.org/Features/Management_Network_As_A_Role), hosted-engine-setup should better let its user choose the name of the bridge to be created (and have ovirtmgmt as default).

Comment 6 Sandro Bonazzola 2015-06-19 08:45:15 UTC
According to comment #5 I've updated the subject of the bug.
This changes a bit the scope of the bug moving it from downstream only to a common change which require coding and not just dropping branding.

Yaniv please review.

Comment 7 Sandro Bonazzola 2015-06-19 08:55:35 UTC
Moving back to network vertical, since this is part of their feature Management_Network_As_A_Role.

Comment 8 Yaniv Lavi 2015-06-29 10:02:14 UTC
(In reply to Sandro Bonazzola from comment #6)
> According to comment #5 I've updated the subject of the bug.
> This changes a bit the scope of the bug moving it from downstream only to a
> common change which require coding and not just dropping branding.
> 
> Yaniv please review.

Can we use the default for 3.6 and add ability network name to choose in 4.0 for HE?

Comment 9 Sandro Bonazzola 2015-06-29 11:19:37 UTC
(In reply to Yaniv Dary from comment #8)

> Can we use the default for 3.6 and add ability network name to choose in 4.0
> for HE?

I think that leaving Hosted Engine Host not aligned with the other hosts supporting Management Network as a Role Feature will lead to have issues.
But I'm ok for dropping rhevm branding on Hosted Engine as first step.

Comment 10 Sandro Bonazzola 2015-07-06 09:13:37 UTC
Not sure why a network vertical feature has moved to integration bug, but I won't start a fight on the whiteboard. Nacking on capacity for now.

Comment 11 Yaniv Lavi 2015-08-09 17:26:27 UTC
Does hosted engine work basically with these changes?
Even if we don't let the user choose in setup time, the engine can not break from this. Raising priority.

Comment 12 Sandro Bonazzola 2015-08-10 06:13:58 UTC
(In reply to Yaniv Dary from comment #11)
> Does hosted engine work basically with these changes?
> Even if we don't let the user choose in setup time, the engine can not break
> from this. Raising priority.

We'll check when we'll start building downstream and we'll fix accordingly.

Comment 13 Simone Tiraboschi 2015-09-30 08:42:51 UTC
engine-setup will create by default only the ovirtmgmt network.
So we need also to call an API to rename it when the engine is ready ( https://bugzilla.redhat.com/show_bug.cgi?id=1224778#c9 ) otherwise hosted-engine-setup will block requiring a manual action cause the bridge name will not match the logical network name and so the host will not come up.

Comment 14 Sandro Bonazzola 2015-10-02 15:10:18 UTC
Not blocking ovirt 3.6.0 GA on this, proposing for 3.6.1 since without the changes described in comment #13 the feature won't work fully automated with hosted engine.

Comment 16 Yaniv Lavi 2015-11-17 12:35:13 UTC
*** Bug 1224778 has been marked as a duplicate of this bug. ***

Comment 17 Sandro Bonazzola 2016-01-21 14:49:21 UTC
Dropping capacity NACK since this has been re-targeted to 4.0

Comment 18 Sandro Bonazzola 2016-01-21 14:50:58 UTC
Not blocking bug #1224778 because it has been already closed as duplicate of this bug.

Comment 19 Sandro Bonazzola 2016-01-21 14:52:21 UTC
moving bug #1231379 out of blocked to see also. It has been already verified so it can't really be blocked by this one.

Comment 20 Yaniv Kaul 2016-03-02 21:40:26 UTC
Reminder that we hope to move to OVS in 4.0. I assume similar logic should happen, but with OVS.

Comment 21 Yaniv Lavi 2016-03-02 22:40:42 UTC
(In reply to Yaniv Kaul from comment #20)
> Reminder that we hope to move to OVS in 4.0. I assume similar logic should
> happen, but with OVS.

We are not moving to OVS, it will not be on for older cluster and i would prefer HE stays with same networking for now.

Comment 22 Dan Kenigsberg 2017-05-14 10:18:16 UTC
As Simone explained, bridgeName does not propagate into the Engine VM, which has ovirtmgmt hard-coded. bridgeName is useful only when migrating an independent Engine with "rhevm" to hosted-engine.

Simone, can you move this bug to docs (and explain how, when, and the limitations of OVEHOSTED_NETWORK/bridgeName)?

Comment 23 Yaniv Lavi 2017-05-29 10:59:25 UTC
(In reply to Dan Kenigsberg from comment #22)
> As Simone explained, bridgeName does not propagate into the Engine VM, which
> has ovirtmgmt hard-coded. bridgeName is useful only when migrating an
> independent Engine with "rhevm" to hosted-engine.
> 
> Simone, can you move this bug to docs (and explain how, when, and the
> limitations of OVEHOSTED_NETWORK/bridgeName)?

This should not move to docs.
Please move BZ #1449547 with the details on the workaround.

Comment 24 Simone Tiraboschi 2017-09-20 09:35:08 UTC
ovirtmgmt is currently hardcoded in more than one place in DB initialization scripts:

https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00900_insert_network.sql#L9

https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/01900_insert_vnic_profiles.sql#L9

https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/upgrade/pre_upgrade/0000_config.sql#L368

...


So up to now we cannot simply pass a different value to engine-setup via answer-file: the user can switch to a different management network via UI or APIs but AFAIK it requires the datacenter to be up and so it's not a trivial change during bootstrap process.

OVEHOSTED_NETWORK/bridgeName could be just used on hosted-engine-setup side when restoring a DB of a previous existing engine with a custom/different management bridge name to honor it.

Simply injecting it on fresh deployment will make it failing.

Comment 25 Yaniv Lavi 2018-06-06 12:27:05 UTC
Closing old RFEs. Please reopen if needed.
Patches are welcome.