Bug 1301323 - Editing a Provider/Host IP Address resets the value to the FQDN
Editing a Provider/Host IP Address resets the value to the FQDN
Status: CLOSED NOTABUG
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
5.5.0
Unspecified Unspecified
medium Severity medium
: GA
: cfme-future
Assigned To: Marcel Hild
Jeff Teehan
provider:scvmm:network
:
: 1301324 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-24 01:36 EST by Jeff Teehan
Modified: 2016-12-20 11:05 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 11:05:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Teehan 2016-01-24 01:36:12 EST
Description of problem:

I needed to set the Host Name to an IP Address rather than FQDN as the name doesn't resolve.  I also set the Default and Remote passwords (windows systems).  The password was wrong, so I went back in to change it, only now the IP Address had been replaced with the FQDN.  This further confused my test.

So, if a user sets the Host Name to be an IP address, we should not reset the value when editing the host.

Version-Release number of selected component (if applicable):
5.5.2.2 (verified with 5.5.0 as well)

How reproducible: It doesn't reset right away, but will after a few actions.  I'll polish up the steps.  It's not a big bug.


Steps to Reproduce:
1. Modify the Host Name field by editing a Provider/Host and use an IP Address.
2. Save the Changes
3. Navigate to Virtual Machines and then back to Hosts

Actual results:


Expected results:


Additional info:
Comment 2 Marcel Hild 2016-02-11 15:14:29 EST
Jeff, thanks for the detailed description of the issue.

1) Have you seen this behavior also on the other providers or only for scvmm
2) On a side note: I wonder how the IP got resolved to FQDN, as you said the name does not resolve. Is there only reverse lookup for that IP?
Comment 3 Marcel Hild 2016-02-22 04:31:32 EST
jeff, are you able to reproduce this issue on another provider, eg. vmware?
Comment 4 Jeff Teehan 2016-02-23 11:46:10 EST
Yes it does.

I editted an ESX host by IP address and save.  Verified it has the IP address for the host name.  Then I clicked on Virtual Machines link and went off to work on something else for 10 minutes.  Upon return, I clicked on hosts again.  The ESX name was already back to fqdn and when I edited the host, it has the fqdn.

So this appears to be a generic host issue.
Comment 5 Jeff Teehan 2016-02-23 11:58:44 EST
*** Bug 1301324 has been marked as a duplicate of this bug. ***
Comment 6 Marcel Hild 2016-12-20 10:21:36 EST
Jeff,
cleaning up stale BZs. Do you remember where you updated the Hostname? On the appliance I guess.

Now the `hostname` field is updated during a refresh. I'm not sure if editing a hostname should even be possible.
Comment 7 Jeff Teehan 2016-12-20 11:05:01 EST
I wrote this when I didn't know what I was doing.  Turns out my domain controller was not updating to the rhq domain controller.  So I did what any network engineer would do and added the hyper-v hosts to the /etc/hosts file.  If I use an appliance on the main domain, it works fine.

Closing this as not a bug and moving on.  Thanks Marcel for all the time you spent looking at it and helping me out.

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