Refs #16134 - deploy hostname override fact #100
Conversation
|
So we are deploying a custom fact with the full hostname whenever the booststrap RPM is installed? |
|
@ehelms yep, that is the goal. There will be a followup PR to katello to support this fact. In addition subscription-manager is going to support a fqdn fact in the future. So the katello PR will basically work off this priority: future sub-man fqdn fact |
|
This will incorrectly report if the hostname is changed at any point without the host being re-bootstrapped, correct? Maybe an edge case, but given we prefer this override over currently provided facts, can we account for that potentiality? |
|
@ehelms that is a downside to this approach. Any ideas? :) |
|
@jlsherrill when does sub-man update its hostname fact? |
|
@ehelms it updates it at checkin time (every 4 hours). However today we do not change a host's name based on a sub-man fact change as there could be implications of that change (dns/dhcp updates). Hostname changes today require either re-registration, or going into the UI and manually changing the host's name. If we're okay requiring the user to perform some action when changing the hostname of the system
|
|
Have also opened a katello PR to utilize the new facts Katello/katello#6328 however they get set |
|
@ehelms it looks like its possible write a plugin for sub-man that could intercept fact uploading. We could ship that as part of katello-agent or in a stand-alone package. There aren't any examples of that that i know of, it'd be the first sub-man plugin we've written, although it looks very similar to yum. with puppet, i believe if you updated the hostname (and cleared the puppet certs) and puppet checked in it would create a new host since that is the identifying information. |
|
What do you think is less work, adding the reset to when katello-agent is restarted or the sub-man plugin? I realize we are talking an edge case, but our users have taught us that edge cases are reality (such as the problem this is trying to solve). |
|
A plugin isn't difficult, more complex than the katello-agent change but much preferred. Will open a pr for that against the katello-agent repo (although i will likely add a sub-package within katello-agent). However what happens in this Pr still needs to occur in order for the client to be able to get the package providing the sub-man plugin |
| @@ -95,6 +95,11 @@ fi | |||
| service goferd status >/dev/null && \ | |||
| service goferd restart >/dev/null 2&>1 | |||
|
|
|||
|
|
|||
| if [ -d /etc/rhsm/facts/ ]; then | |||
| echo "{\"network.hostname-override\":\"`hostname -f`\"}" > /etc/rhsm/facts/katello.facts | |||
There was a problem hiding this comment.
Why don't we want to deploy this fact as 'fqdn' to match the katello-agent/sub-man plugin?
There was a problem hiding this comment.
The reason for that was because facts in this directory override any generated facts. So if we used fqdn here, the plugin would never have affect, and future sub-mans would never have any affect. We want this 'hostname-override' fact to only affect the registration until a) the sub-man plugin is installed or b) future subman is installed which natively supports this fact.
Notice that the plugin only sets the fact if it doesn't already exist (so that the future sub-man's behavior takes priority).
There was a problem hiding this comment.
Make sense. Last question, override makes some sense, however hostname -f is a valid value and fact. Would it be worth calling it hostname-full ?
There was a problem hiding this comment.
It was meant more as a temporary workaround fact that only exists to help with issue. The fact it also never would actually be updated further reinforces to me that the name should indicate that its not a 'real' fact that should be depended on by users. I wouldn't want to see:
hostname: foo
fqdn: foo.example.com
hostname-full: someother.name.that.is.no.longer.valid
versus:
hostname-override: someother.name.that.is.no.longer.valid
not saying hostname-override is a fantastic name, but i figured it should not appear 'normal'.
@jlsherrill I don't quite get that? I get we need to install it but not sure why this needs to happen? I've just hit this problem using a VMWare template that already has the bootstrap RPM installed and it registering against the wrong machine. |
|
@sean797 sorry just noticed your comment. what exactly was your problem? Was the fqdn not set correctly on the vm or something? |
No description provided.