Project

General

Profile

Actions

Bug #19430

closed

Setting the primary interface to another interface as the provisioning interface doesn't work.

Added by Han Boetes about 7 years ago. Updated about 7 years ago.

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

Description

According to the foreman webui the primary interface(PRI) is used for constructing the FQDN and the provisioning interface(PRO) is used for provisioning.

I would expect that during provisioning the PRO is configured with DHCP and that after the installation I can use puppet to finish the configuration including the PRI.

But if I set the PRO to eth0 and PRI to eth1 during provisioning, eth1 is configured and the provisioning fails.

This forces me to set eth0 to PRI and PRO during the installation. I think that's bug. The effective end result is that in the end the hosts end up with the wrong FQDN.


Related issues 1 (1 open0 closed)

Related to Foreman - Bug #1485: unable to rename hostsNew02/07/2012Actions
Actions #1

Updated by Han Boetes about 7 years ago

Another interesting related problem is that if I change the PRI to the right interface after provisioning the FQDN stays the same for puppet, even though the WEBUI shows the right FQDN.

Actions #2

Updated by Marek Hulán about 7 years ago

I'm not sure whether you intentionally reported this against hammer CLI, does the same happen when you provision the host from UI? You're right about primary interface, the FQDN is determined based on that. Provisioning interface only determines, what TFTP proxy should be used for PXE boot. All the rest goes through primary interface, e.g. anaconda/deb installer downloads all packages through primary interface network.

If you want to keep some interface unconfigured and do it via puppet later, just set it as manage = false, that should skip all DHCP/DNS records creation.

Actions #3

Updated by Han Boetes about 7 years ago

No I was not aware I reported against hammer and I didn't intend to do so. I was using the WebUI.
Oh well, I'll use puppet all the way after installing. Too bad the host will keep the wrong fqdn.

Actions #4

Updated by Marek Hulán about 7 years ago

  • Project changed from Hammer CLI to Foreman
  • Status changed from New to Resolved

Is the correct name not known before the host is fully provisioned? In such case I don't think there's an automated easy way to modify puppet certificate after the provisioning is done. Anyway, I'm moving this issue in to Foreman and marking as resolved. Please let us know if you wish to reopen it.

Actions #5

Updated by Han Boetes about 7 years ago

The correct hostname is known, but setting the official domain name on the provisioning subnet is counter intuitive to me. I'd like to set that on the primary interface, the interface which has the default gateway and provides access to it's services. The provisioning interface is for administration and puppet access.

Actions #6

Updated by Marek Hulán about 7 years ago

  • Category set to Orchestration

I see. There's the old issue that host can't be renamed - #1485 so when someone gets to it, I bet he or she will have to reproduce and see what would need to be done in order to do the full rename of provisioned host.

Actions #7

Updated by Marek Hulán about 7 years ago

  • Related to Bug #1485: unable to rename hosts added
Actions

Also available in: Atom PDF