Project

General

Profile

Actions

Bug #10602

closed

Unable to change a host's primary interface

Added by Trey Dockendorf almost 9 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Network
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

If I have a host with a setup like this:

eth0
eth1: primary + provisioning named test.domain

And I attempt to change eth0 to the primary interface because eth1 is actually on a private network I get a validation error of "Some of the interfaces are invalid. Please check the table below." and eth0 is highlighted. I select Edit for eth0 and it says the DNS name is already taken. If I attempt this operation again but also remove the DNS name and domain from eth1 the validation still fails for the same reason. The only way I've been able to modify a host's primary interface has been by giving the new primary interface a completely new name. This results in the host having a new, incorrect, FQDN which I then have to go back in and change back to the original hostname.

My guess is the validation is failing because the removal of the DNS name from eth1 hasn't taken place yet so the uniqueness constraint is validated.

Actions #1

Updated by Marek Hulán almost 9 years ago

  • Category set to Network
Actions #2

Updated by Marek Hulán almost 9 years ago

If I understand correctly, you're trying to change the FQDN on one interface to value that currently has the second interface, is that correct? If I'm wrong, please provide some examples of DNS name and Domains you're using to better illustrate what you're trying to achieve. There are some limitations in validations for which we don't have currently a good solution in WebUI, you can try using API to modify interface that runs validations separately.

Actions #3

Updated by Trey Dockendorf almost 9 years ago

That is correct. I have found this behavior is still the same with 1.8.2. For some reason upgrading from previous version (1.6.x) to 1.8.x resulted in the wrong interface being marked as "Primary". On most of my systems the "Primary" interface is public facing and is what sets the FQDN. The "Provision" interface is private and in most cases has no hostname associated, just an IP. So far the only way to put the FQDN on the correct interface is to give it a fake FQDN. So if the host was "web0.tamu.edu" I have to give it the host name "web0p" and associate it to domain "tamu.edu". Then before saving I have to remove the host name and domain association on the non-primary interface. Once saved I have to go back and remove the "p" from the hostname so the system is correctly called "web0.tamu.edu".

The rename operation isn't a huge problem in this environment as I don't yet manage DNS with Foreman. I do one day hope to manage DNS and can see this being an issue where Foreman would start creating DNS and/or DHCP entries for this fake name that is only used to work around the validation.

Actions #4

Updated by Bryan Anderson over 8 years ago

I also am seeing this issue when using discovery. It sets my primary interface correctly, and then when I configure a network bridge and the new primary interface is br0 I can't update it. Foreman says the name is already taken but I can't remove the name from the previous primary interface. If I try to remove the name from one interface (e.g eth0) and move it to the other (e.g br0) same error. If I try to remove the name first I get a "No Route matches".

Actions #5

Updated by Marek Hulán about 7 years ago

  • Status changed from New to Feedback

There were couple of improvements in validations of interfaces. I believe interfaces are now validated in right scope so errors like "name has already been taken" should not appear. If you're still experience the issue with recent Foreman, please let us know what version is that and we'd reopen.

Actions #6

Updated by Anonymous about 7 years ago

  • Status changed from Feedback to Resolved

no reaction, closing

Actions

Also available in: Atom PDF