Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #36731 - Use facts, not operatingsystem name, to identify RHEL hosts #10738

Merged
merged 3 commits into from
Sep 28, 2023

Conversation

jeremylenz
Copy link
Member

What are the changes introduced in this pull request?

When determining the host status for RHEL lifecycle, do what's described in the PR title.

Considerations taken when implementing this change?

We now rely on sub-man facts instead of operatingsystem name, which is a bit more reliable. These facts won't be present for "unmanaged" hosts, but that's okay because we only care about managed hosts.

What are the testing steps for this pull request?

In rails console, run

Host.all.each(&:refresh_statuses)

Then check all host statuses and make sure they are still as expected.

@theforeman-bot
Copy link

Issues: #36731

@ehelms
Copy link
Member

ehelms commented Sep 15, 2023

@ekohl mind taking a look? I recommend part of this approach based on my knowledge, but I think it's worth you checking the approach.

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some context: there is a setting ignore_facts_for_operatingsystem which can be used to either update the OS based on facts or disable it. The default is false, so (double negative) the default is to update the OS based on facts.

Some users don't like that syncing very much, so they disable it. There has been discussion about always storing it in a reported data facet. Then you can, even if you disable syncing, always easily use the parsed data. The idea being that application code should never use the raw facts but always handled processed data.

My biggest worry is cost. I think loading facts is pretty expensive, especially if you have a lot of them.

Perhaps this is a good excuse to move forward storing the OS as a reported data facet and then consume it here.

app/models/katello/concerns/host_managed_extensions.rb Outdated Show resolved Hide resolved
app/models/katello/concerns/host_managed_extensions.rb Outdated Show resolved Hide resolved
app/models/katello/concerns/host_managed_extensions.rb Outdated Show resolved Hide resolved
@jeremylenz
Copy link
Member Author

My biggest worry is cost. I think loading facts is pretty expensive, especially if you have a lot of them.

I've been noticing this as well, as I'm also working on theforeman/foreman#9819

Once that's merged I can update this to take advantage of it.

Also, this particular use case of facts shouldn't be too bad, since the status is only updated on host check-in, and will occur in a staggered fashion and not for all hosts at once.

@jeremylenz
Copy link
Member Author

Updated to take advantage of theforeman/foreman#9819 which is now merged.

def probably_rhel?
# Get the os name from sub-man facts rather than operatingsystem. This is
# less likely to have been changed by the user.
os_name, = facts('distribution::name').values # only query for that one fact, then get its value
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using facts('distribution::name') here instead of facts['distribution::name'] because this guarantees that the SQL query will only retrieve that one fact, not all facts for the host.

With the comma, this line is equivalent to

os_name = facts('distribution::name').values.first

but avoids the need for safe navigation (&.).

Copy link
Member

@lfu lfu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍🏻

@lfu
Copy link
Member

lfu commented Sep 27, 2023

Would you sqash your commits?

@jeremylenz jeremylenz merged commit cdbc701 into Katello:master Sep 28, 2023
4 of 5 checks passed
@jeremylenz
Copy link
Member Author

@lfu squashed and merged, thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants