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:
(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 .
(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?
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 :-)
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.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
We will only supported adding additional hosts from the UI/REST from 4.0. Therefore closing this bug.