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.
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 open — 0 closed)
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.
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.
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.
- 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.
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.
- 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.
- Related to Bug #1485: unable to rename hosts added
Also available in: Atom
PDF
Updated by 
Updated by