Bug 1269428 - On additional hosts, hosted-engine-setup lets the user specify the interface to create the managemnt bridge on but then ignores it
On additional hosts, hosted-engine-setup lets the user specify the interface ...
Status: CLOSED DUPLICATE of bug 1269430
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: Network (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Yedidyah Bar David
Ilanit Stein
Depends On:
  Show dependency treegraph
Reported: 2015-10-07 06:12 EDT by Simone Tiraboschi
Modified: 2015-10-07 06:16 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-07 06:16:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Simone Tiraboschi 2015-10-07 06:12:57 EDT
Description of problem:

On the first host we explicitly ask the user which interface he want to use for the management bridge.
Then we directly call setupNetworks on vdsm in order to be able to bootstrap a virtual machine to install the engine on; this happens before having an engine VM.
When the engine is ready, hosted-engine-setup calls host.add on the engine REST API and this triggers host deploy to close the loop.
Host-deploy will simply find an already existing bridge (the one we created to bootstrap the VM) and it just uses that.

On additional hosts we still let the user select an interface but then we just call host.add. Now it's up to host-deploy to create the bridge cause it's not there on fresh hosts.
In the past (<= 3.5.3 I think) we were adding the host using the IP address of the selected nic as the host address and so host-deploy will contact it there and creates the bridge on that interface.
Due to an issue on the cert signing then we decided to move to have the host certs being signed on the hostname and not on the IP address and so we are now adding the host using its fqdn.

So now the engine resolves that fqdn and host-deploy creates the bridge on the interface with the IP that has been resolved by the host.
This still makes sense and it's basically what happens when you add a regular (not HE) host from the web ui the issue is that we let the user specify an interface for the management bridge but than we ignored it.

So now we have two alternatives:
1. directly create the bridge on the interface specified by the user before calling host.add as we do for the first host
2. simply remove that messy question for additional hosts behaving as the engine does for regular hosts. The user will implicitly select the interface just configuring his networking or he will fix the configuration as he does for regular hosts.  

I'm for option 2

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. deploy HE
2. start deploying additional host and than select a different interface for the management bridge

Actual results:
It ignores the user specified interface letting host-deploy choose based on the IP address the engine resolved the host FQDN

Expected results:
Two alternatives:
1. it honors the user selection
2. it doesn't ask simply behaving as for regular hosts

Additional info:
Personally I'm for solution number 2.
Comment 1 Simone Tiraboschi 2015-10-07 06:16:40 EDT

*** This bug has been marked as a duplicate of bug 1269430 ***

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