Bug 1317996 - On additional hosts hosted-engine-setup don't ask about about the management interface or the hostname
Summary: On additional hosts hosted-engine-setup don't ask about about the management ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: Network
Version: 1.3.4.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.0.0-rc
: ---
Assignee: Simone Tiraboschi
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On:
Blocks: 1318992
TreeView+ depends on / blocked
 
Reported: 2016-03-15 17:45 UTC by Simone Tiraboschi
Modified: 2017-05-11 09:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-02 08:19:28 UTC
oVirt Team: Integration
ylavi: ovirt-4.0.0?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1251968 None CLOSED [Tracker] - Hosted engine setup fails with localhost.localdomain could not be used as a valid FQDN 2019-03-28 08:31:57 UTC

Internal Links: 1251968

Description Simone Tiraboschi 2016-03-15 17:45:21 UTC
Description of problem:
On additional hosts hosted-engine-setup don't ask about about the management interface or the hostname.

Host-deploy will create the management bridge on the interface where the host address resolves on; for regular hosts added via web-ui the use can simply use an address that specifically resolves on a specific interface.

If the host has multiple interface on different subnet currently nothing will ensure that the management bridge will be created on the right one.
The host will remain non-operation and hosted-engine-setup will loop till the user fixes it from the web UI correctly binding it. This could break automated setups. 

Version-Release number of selected component (if applicable):
ovirt-hosted-engine-setup-1.3.4.0

How reproducible:
100%

Steps to Reproduce:
1. deploy hosted-engine
2. add an additional host
3.

Actual results:
on additional host hosted-engine-setup simply uses socket.getfqdn()


Expected results:
For special network configuration it would be better to let the user specify an hostname that resolves to a different interface or directly an interface (as for the first host) and gather the hostname from there.

Additional info:

Comment 1 Yedidyah Bar David 2016-03-16 07:39:00 UTC
(In reply to Simone Tiraboschi from comment #0)
> Description of problem:
> On additional hosts hosted-engine-setup don't ask about about the management
> interface or the hostname.

> Actual results:
> on additional host hosted-engine-setup simply uses socket.getfqdn()
> 
> 
> Expected results:
> For special network configuration it would be better to let the user specify
> an hostname that resolves to a different interface or directly an interface
> (as for the first host) and gather the hostname from there.
> 

So I do not understand: Do query for the hostname, or rely on socket.getfqdn()?

I agree about not asking for the interface, but think we should always query for hostname. See also bug 1188675 .

Comment 2 Simone Tiraboschi 2016-03-16 09:35:38 UTC
(In reply to Yedidyah Bar David from comment #1)
> I agree about not asking for the interface, but think we should always query
> for hostname. See also bug 1188675 .

Basically the requirement is that the engine VM and the hosts must be in the same subnet, the issue is that in engine_api.hosts.add call we can just pass an address (hostname) parameter and we cannot, currently, add a subnet or an interface hint so the interface will just be implicitly selected. 

Current code:
- on first host asks for an interface, creates the bridge there (because we need it before starting the engine VM) and look up for an hostname that resolves only there with socket.gethostbyaddr(ipaddr)
- on additional hosts it simply uses socket.getfqdn() which can lead to ambiguous situation if more than one hostname and more than one subnet are configured on the host.

The setup will probably not break but it can pause with
          The host hosted_engine_2 is in non-operational state.
          Please try to activate it via the engine webadmin UI.
          Retry checking host status or ignore this and continue (Retry, Ignore)[Retry]?
Asking to the user to manually fix the network configuration before continuing and this could be annoying on automated setups.

So two options there:
1. list all the available hostname we found on the host and let the user choose one ensuring that it resolved only on one interface (the hostname implicitly sets the interface)
2. let the user choose an interface, get the hostname from there and ensure that it resolves only there (the user directly selects the interface as on the first host but the hostname should be correctly assigned)

Danken, any other idea?

Comment 3 Yedidyah Bar David 2016-03-16 09:46:01 UTC
Please do not mix "hostname" with "Reverse-lookup the IP address of a NIC".

Users should be able, if they want, to have a host with hostname 'host1', and with NICs nic1,nic2, IP addresses IP1,IP2, and reverse-resolution on these to be 'host1-nic1', 'host1-nic2', also forward resolution on these to be IP1, IP2. And then have in the dns, if they want, 'host1 CNAME host1-nic1', and supply fqdn 'host1', or 'host1-nic1', when prompted. They should be able to design whatever naming convention, and we should adapt.

We should always query for the fqdn they want to use. That's exactly like adding a host in the web interface.

Relying on that for deciding which interface to use is ok, imo, and also ok is that if this fails, we prompt to manually fix and retry. IMO :-)

Comment 4 Yaniv Lavi 2016-03-17 09:22:38 UTC
We will be looking to make adding a hosted engine host supported only via the WebAdmin which should resolve this issue. I would wait for that and then this ticket can be closed.

Comment 5 Sandro Bonazzola 2016-05-02 09:59:12 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 6 Yaniv Lavi 2016-05-23 13:15:59 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 7 Yaniv Lavi 2016-05-23 13:19:50 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 8 Yaniv Lavi 2016-06-02 08:19:28 UTC
We will only supported adding additional hosts from the UI/REST from 4.0. Therefore closing this bug.


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