Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 983295

Summary:	Unable to bypass FQDN requirement for rhevm-setup
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Bryan Yount <byount>
Component:	ovirt-engine-setup	Assignee:	Sandro Bonazzola <sbonazzo>
Status:	CLOSED ERRATA	QA Contact:	Ilanit Stein <istein>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2.0	CC:	acathrow, adahms, alonbl, bazulay, cnegus, cpelland, iheim, jkt, mgoldboi, Rhev-m-bugs, sbonazzo
Target Milestone:	---	Keywords:	ZStream
Target Release:	3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:	is6	Doc Type:	Bug Fix
Doc Text:	Previously, when installing Red Hat Enterprise Virtualization Manager, the system would not allow installation to proceed unless a fully qualified domain name (FQDN) was specified. This caused problems under some conditions, such attempting to install the Red Hat Enterprise Virtualization Manager in a lab where an FQDN may not be available. With this update, the Red Hat Enterprise Virtualization Manager can now be installed without specifying an FQDN unless in all-in-one configuration.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-21 17:34:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1005851

Description Bryan Yount 2013-07-10 22:03:37 UTC

Description of problem:
When installing RHEV-M 3.2 in a lab or test environment where a FQDN might not always be available, the rhevm-setup script does not allow the user to bypass the FQDN requirement. While I agree that forcing FQDN for an enterprise product is the way to go, there should be a --flag to bypass this for certain instances if the user is made aware of the risks.

Version-Release number of selected component (if applicable):
rhevm-setup-3.2.0-11.33

How reproducible:
Very

Steps to Reproduce:
1. Configure a RHEL system without a FQDN such as an internal dynamic DNS environment in a lab
2. yum install rhevm
3. rhevm-setup

Actual results:
Install fails with error "Host fully qualified domain name. Note: this name should be fully resolvable  [quimby] : quimby.usersys.redhat.com"
The IP XX.XX.XX.XX does not hold a PTR record for the FQDN: quimby.usersys.redhat.com

Expected results:
The installer should have a --flag to allow the user to bypass the FQDN requirement and alert them of the risks and possibly require an additional Y/N answer.

Additional info:
This is necessary for setting up many of our internal Red Hat test environments.

Comment 2 Alon Bar-Lev 2013-07-11 07:22:59 UTC

This is in place because of these reasons:

1. libvirt requirement, as far as we know it tries to resolve the name and reverse resolve name when performing migration, so in aio configuration this is important.

2. ovirt-node/rhev-h require to access the engine via ssl, and host name must be resolvable.

3. users require to access the engine via ssl, and in order to avoid errors regarding host name mismatch there should be proper naming services.

But manual bypassing is important, and we have just had a discussion about this[1]

And in new installer we limited the reverse resolve to the aio configuration.

[1] http://gerrit.ovirt.org/#/c/16543/

Comment 3 Alon Bar-Lev 2013-08-14 09:10:33 UTC

Moran,
This should be closed as CANTFIX or NOTBUG or anything...
Thanks,

Comment 4 Bryan Yount 2013-08-19 17:37:48 UTC

(In reply to Alon Bar-Lev from comment #2)
> But manual bypassing is important, and we have just had a discussion about
> this[1]
> 
> And in new installer we limited the reverse resolve to the aio configuration.
> 
> [1] http://gerrit.ovirt.org/#/c/16543/

Can we fix this in the next RHEV 3.2.z installer? Upping priority to high. This severely limits our ability to install RHEV in a lab environment that might not have DNS but where we could fake it with /etc/hosts entry.

Also, think about the customers... what if a customer wants to do a POC of RHEV but they don't have DNS for that environment? They will be dead in the water unless they install RHEV 3.1 first.

Comment 5 Chris Negus 2013-08-19 17:48:29 UTC

Forcing the RHEVM FQDN to forward/reverse resolve during rhevm-setup also breaks the procedure we are using for RHEV-M on HA cluster (https://access.redhat.com/site/node/216973). We don't set the IP address for the RHEV-M until we set up the cluster some time after rhevm-setup. That's because that IP address needs to move among different cluster nodes.

Comment 7 Alon Bar-Lev 2013-08-28 23:18:29 UTC

This should be resolved in 3.3.

Comment 8 Ilanit Stein 2013-09-01 06:50:12 UTC

This is not resolved yet on current formal release sf20.1 (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4.

Comment 9 Alon Bar-Lev 2013-09-01 08:32:03 UTC

(In reply to Ilanit Stein from comment #8)
> This is not resolved yet on current formal release sf20.1
> (rhevm-3.2.3-0.42.el6ev.noarch). Target release here is 3.2.4.

This is not cloned bug for 3.2.z, it is the bug for 3.3.0.

Comment 10 Ilanit Stein 2013-09-08 08:05:48 UTC

Verified on is12: invalid fqdn in non interactive mode indeed allowed.

Comment 12 Charlie 2013-11-28 00:08:44 UTC

This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 14 errata-xmlrpc 2014-01-21 17:34:08 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0038.html