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.
*** Bug 1231836 has been marked as a duplicate of this bug. ***
Upgrades should keep the same network name, only change in clean installations.
(In reply to Yaniv Dary from comment #2)
> Upgrades should keep the same network name, only change in clean
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.
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).
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.
Moving back to network vertical, since this is part of their feature Management_Network_As_A_Role.
(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?
(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.
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.
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.
(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.
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.
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.
*** Bug 1224778 has been marked as a duplicate of this bug. ***
Dropping capacity NACK since this has been re-targeted to 4.0
Not blocking bug #1224778 because it has been already closed as duplicate of this bug.
moving bug #1231379 out of blocked to see also. It has been already verified so it can't really be blocked by this one.
Reminder that we hope to move to OVS in 4.0. I assume similar logic should happen, but with OVS.
(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.
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)?
(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.
ovirtmgmt is currently hardcoded in more than one place in DB initialization scripts:
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.
Closing old RFEs. Please reopen if needed.
Patches are welcome.