Can we drop the append domain names to the host setting?

Hello there,

as part of simplifying the Foreman configuration, I’d like to ask whether it would hurt if we remove the “Append domain names to the host” from Settings → General.

The only use of it is in the host form where it automatically appends the selected domain name to the host FQDN. It is known to cause problems with Ansible roles run.I found @James_Shewey is using it according to this, James do you have any insights for the use case and the need? If I’m not missing anything, it’s just about hiding the (potentially made up) domain in the host list, which may be nice in some smaller setups.

Thanks for any comments, if we don’t find a good use, we’d deprecate this in 3.4 and drop in 3.5.

1 Like

First of all, the setting is defined here:

When you say drop the setting, do you mean making the behavior match the current default value (true)?

Then my understanding of the feature: if you set this to false, your database will have hosts only by their short name: myhost instead of

Then some more related matters. I know we also have a problem with this in the installer and the host registration (which was introduced in Foreman 3.1 via Feature #33789: Mark host where the installer is running as foreman when deploying foreman - Installer - Foreman). Here it assumes the host is the FQDN but that fails if hosts within Foreman are registered without a domain:
puppet-foreman/register.pp at e0fc1487740d36a5a308498576836525d3e52de1 · theforeman/puppet-foreman · GitHub

A similar problem shows up on the Smart Proxy registration:

We can work around it, but it’d be ugly.

That said, this did show up within Satellite so I believe it was a customer who was using it. Their use case was that they moved systems around and changed their domain names and hosts ended up being duplicated. I think that by having the short name in Foreman, Puppet certificates (and probably others) end up having a short name as well. That was their way to work around it.

IMHO having all hosts properly registered with their FQDN is a good thing, but the use case of changing the domain can be a good one.

In particular for Puppet, there is an option to generate the certificate name as an UUID which removes the hostname from the equation altogether. IMHO that’s a good solution when the hostname is unstable. Perhaps there are more cases that could be solved in a similar manner.

Then there is also the matter of migration. Does it mean all hosts in the existing databases need to be appended a domain? Can we do this automatically? Would things break?

So in short: I’d be in favor of deprecating and removing this setting if we can still account for the use cases (which I believe we can) and have a proper migration strategy.

I would also hope to not need the setting. But I know different environments where the same hostname but a different domainname is used in the different stages, so we should change the behaviour to the same as the setting being true. On the other side I also have environments where in general the FQDN is used, but for some reasons in e.g. VMware not.

So in general I agree with the proposed change and Ewoud’s additions, but I fear we will find someone who is unhappy with it.

Yes, as that’s what most users have.

Not necessarily but very likely. You can still have FQDN in the name, this setting really is about what is stored by default to the host name attribute, whether’s it’s its shortname or FQDN. One can still enter the FQDN into the host name text field.

In case we want to solve the migration, this could be quite straightforward for managed hosts. We’d append the the domain of the primary interface or even better, we’d drop the setting (and make it always on) and refresh host names using the NameSynchronizer. I don’t think it’s ever realistic to list what all may break, important thing is, we still have access to shortname and FQDN. If we need to add additional layer somewhere, we can still do it, e.g. like with the certname attribute for Puppet certificate.

I’d though argue that given we already have this as a setting and user may flip this at any time, it should not be breaking anything dramatically. And also that it’s like we enabled the Setting for everyone and remove the option to drop it. It would be good to test, but new host save should trigger the name synchronizer and that should fix the name according to the new behavior.

Well that’s always a risk, but at this point we don’t know how many such environments/users there are. hence this thread :slight_smile: We may also find out more after it’s in the deprecation list of 3.4. I hope we’ll gather some early user feedback before that though.

Dropping the option to omit the domain name should not be problematic in our experience. Using short names however can create issues. E.g. when pushing facts from an external puppet master used to create an additional host entry with identical hostname used to be created unless using fqdn as apparently the association between the original host in foreman and the incoming facts was not properly done.
Using fqdns only so far created no problems except for come customer’s preference to use short names for “better readability”.

1 Like

Thanks, great feedback!

I can also imagine cutting the domain name in the view layer, e.g. on the host index page, but still storing the FQDN in the database.