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.
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 myhost.example.com.
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.
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 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”.
Sorry I am just now seeing this. In places, we use fqdn domain names programmatically - For example, a host can know what environment it is in by looking at it’s domain:
By parsing the subdomain, I can know what environment I am assigned to. Similarly, we use some crosscheck scripts to generate daily reports for host/hostnames that probably need attention. As much as I want Foreman to be the “book of record” I still find people deploying OVFs directly in VMWare, but forgetting to create a domain name for them or adding them to a few other systems like FreeIPA. (You can’t always get away from this - your hypervisors and networking equipment for example) but by using this setting, I can more easily check for consistency between systems and more easily check in the case of:
If only the short name is used, I run into problems with these scripts, so keeping the option would be preferable in my opinion. Even if you default to short names. The problem I think arises most when you spider out into other systems that aren’t the foreman/katello core. What happens with IDMs DNS when that gets run through smart proxies? What about PowerDNS? And Infoblox? What happens to things that aren’t puppet like SaltStack (to the extent that’s supported any more), Ansible, Chef, or others?
I think keeping this setting gives the most support to the most systems (even if not “supported” any longer) and allows the customer that freedom of choice with minimal other foul-ups in integrations.
Perhaps the proposal wasn’t clear, but we’d keep the domain names appended, in other words, the host name would always contain the domain. If we were to keep the setting, it would only allow to hide the domain in the host list (while internally, it would be still stored as FQDN).
I just came across this thread and figured, it would be great to have an information here, that the change was implemented by https://github.com/theforeman/foreman/pull/9613 and made it to the Foreman 3.9.0
Sadly I missed this change in behavior before doing an upgrade on our Foreman install and all my scripts that talk to the API using the shortname for the ‘id’ stopped working. After fighting that for a few hours I found this thread - so I’m that person mentioned earlier who is unhappy with it.
I was able to update things to use the actual ‘id’ field but using just the short name was so convenient.
Hello, could you give us an example of such API request? I was under the impression, id always required the number. Also I thought hammer had some logic, that would also translate name to the id behind the scene.
Perhaps we could still allow using shortname as another identifier for this API endpoint, though it would still mean, the API use would change.
I’m not sure how to best resolve this given one can have two hosts with the different domain, using short name as the identifier could lead to ambiguity issues.
It would be nice if the old behavior could be enabled with a setting so I can shoot myself in the foot if I want. But I can work around this by updating things to use “id” instead, it just adds some extra steps because most of our external processes that hit the API don’t know that “id” without an extra query to get it.
How complicated would it be to use the domain in the id? I assume your hosts have some “.localdomain” suffix or something, right? The setting was changed because it caused other problems, as it influenced the behavior of host.name. That was problematic e.g. when inventory was synced to some external system, that expect this to be the FQDN.
No, our hosts have a valid FQDNs but the Puppet certificate names are the shortname with no domain. Anything external that needs the FQDN knows to get that fact from the API, but we had some processes that were based on the shortname as used in the Puppet certs. For those processes, they don’t know the FQDN or the ID, so they now pull in a list of all hosts from Foreman to use as a lookup table to find the right ID number to use.
I understand if the behavior change was required to solve issues others had, I can work around it - I just wish I had seen the announcement.
Thanks for the background! @lstejska and @Dyrkon is this something we should more explicit in 3.9 release notes? I guess it’s not too late to add it among upgrade warning as there are likely still users running older versions. It should be put here I think
The Append domain names to the host setting is deprecated and will be removed in a future release. Use FQDN (Fully Qualified Domain Name) to identify the hosts.
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.
given one can have two hosts with the different domain, using short name as the identifier could lead to ambiguity issues.