{"action":"created","issue":{"url":"https://api.github.com/repos/theforeman/foreman/issues/2794","labels_url":"https://api.github.com/repos/theforeman/foreman/issues/2794/labels{/name}","comments_url":"https://api.github.com/repos/theforeman/foreman/issues/2794/comments","events_url":"https://api.github.com/repos/theforeman/foreman/issues/2794/events","html_url":"https://github.com/theforeman/foreman/pull/2794","id":110231242,"number":2794,"title":"Fixes #12083 - Set domain to the most specific existing subdomain","user":{"login":"tbrisker","id":1540531,"avatar_url":"https://avatars.githubusercontent.com/u/1540531?v=3","gravatar_id":"","url":"https://api.github.com/users/tbrisker","html_url":"https://github.com/tbrisker","followers_url":"https://api.github.com/users/tbrisker/followers","following_url":"https://api.github.com/users/tbrisker/following{/other_user}","gists_url":"https://api.github.com/users/tbrisker/gists{/gist_id}","starred_url":"https://api.github.com/users/tbrisker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tbrisker/subscriptions","organizations_url":"https://api.github.com/users/tbrisker/orgs","repos_url":"https://api.github.com/users/tbrisker/repos","events_url":"https://api.github.com/users/tbrisker/events{/privacy}","received_events_url":"https://api.github.com/users/tbrisker/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/theforeman/foreman/labels/Needs%20re-review","name":"Needs re-review","color":"0052cc"},{"url":"https://api.github.com/repos/theforeman/foreman/labels/Needs%20testing","name":"Needs testing","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-10-07T13:57:11Z","updated_at":"2015-10-13T17:57:27Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/theforeman/foreman/pulls/2794","html_url":"https://github.com/theforeman/foreman/pull/2794","diff_url":"https://github.com/theforeman/foreman/pull/2794.diff","patch_url":"https://github.com/theforeman/foreman/pull/2794.patch"},"body":"If there are domains that have subdomains, setting a host name that\r\ncontains the domain name will sometimes choose the wrong domain for\r\nthe host. This patch makes the host pick the most specific existing\r\ndomain automatically."},"comment":{"url":"https://api.github.com/repos/theforeman/foreman/issues/comments/147795962","html_url":"https://github.com/theforeman/foreman/pull/2794#issuecomment-147795962","issue_url":"https://api.github.com/repos/theforeman/foreman/issues/2794","id":147795962,"user":{"login":"dayglojesus","id":317143,"avatar_url":"https://avatars.githubusercontent.com/u/317143?v=3","gravatar_id":"","url":"https://api.github.com/users/dayglojesus","html_url":"https://github.com/dayglojesus","followers_url":"https://api.github.com/users/dayglojesus/followers","following_url":"https://api.github.com/users/dayglojesus/following{/other_user}","gists_url":"https://api.github.com/users/dayglojesus/gists{/gist_id}","starred_url":"https://api.github.com/users/dayglojesus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dayglojesus/subscriptions","organizations_url":"https://api.github.com/users/dayglojesus/orgs","repos_url":"https://api.github.com/users/dayglojesus/repos","events_url":"https://api.github.com/users/dayglojesus/events{/privacy}","received_events_url":"https://api.github.com/users/dayglojesus/received_events","type":"User","site_admin":false},"created_at":"2015-10-13T17:57:27Z","updated_at":"2015-10-13T17:57:27Z","body":"@tbrisker @ares \r\n\r\n> I'm trying to better understand the use case of why we need this matching in the first place.\r\n\r\nI agree. This matching operation is a sort-of-hidden setter method that's been nested inside a hostname validation routine. I do not know why it was added except to supply domain attribute at record creation time. Why this is required, I do not know...\r\n\r\n> What situation leads to needing the domain to be filled automatically from the interface name rather then by choosing the domain from the form (or setting it explicitly via api)?\r\n\r\nUnclear, but the API has never made the `domain` attribute a required param -- only the `name`. I always assumed that the `domain` attribute for a host was derived strictly from imported facts. I think this was true until the large set of changes in Foreman 1.8 wherein primary interfaces became coupled to Foreman host records. Before this, I am pretty sure interfaces were just 'factual' information.\r\n\r\n> Would it make sense to prevent entering dots altogether in the name field for managed interfaces?\r\n\r\nNo, for two reasons:\r\n\r\n1. If the primary interface is have a 'DNS name' (`name`) attribute, this would again prevent the Foreman from using an FQDN as the value for this.\r\n2. Presently, the view implementation for the primary interface will simply munge the Foreman host record name according to its own logic.\r\n\r\nPersonally, I am not sure what the benefit of this coupling is meant to achieve.\r\n\r\nIf you begin to identify a Foreman host record by hardware (real or virtual) that design decision has a far reaching impact. A NIC does not really have a DNS hostname, it binds to an IP, yes, but that relationship is ephemeral insofar as the NIC is concerned. If you then begin assigning synthetic attributes like a DNS name to a piece of hardware, you are doubling down on what is already a tenuous relationship.\r\n\r\nOn the other hand, if you are trying to use the Foreman to manage this information, then I see why the coupling was implemented:\r\n\r\nExample: An edit to the host's primary interface uses a smart proxy to change DNS records.\r\n\r\nIn such a case, the coupling would make sense, but only if you are willing to say... \"DNS is what determines the name of this Foreman record and we're going to let Smart Proxy manage that\".\r\n\r\nIn our case, we DO NOT use a smart proxy to manage DNS. Our DNS is a separate service and will remain that way.\r\n\r\nWhich begs the question... Is the behaviour that we are trying to remedy all in service of 'managed' Host records -- one which use a DNS Smart Proxy?\r\n\r\nNone of our Foreman hosts are fully 'managed' -- that is to say, they are all `Host#managed? == false`.\r\n\r\nIf so, would that imply that the behaviour is simply not scoped properly?\r\n"}}