-
Notifications
You must be signed in to change notification settings - Fork 293
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
Refs #37696 - Don't run sub facet fact parser on non registered hosts #11109
base: master
Are you sure you want to change the base?
Conversation
e8508db
to
4a41739
Compare
* Changed the int4 column on convert2rhel_through_foreman from init4 to boolean * Return out of the fact parser method for hosts that are not registered such as foreman/satellite instance, so we don't error when those systems upload facts * Got rid of build_subscription_facet because the hosts that come from convert2rhel already are registered and have a subscription facet, so no need to build one which also breaks hosts that are not registered through subscription-manager If for some reason we hit an edge case where we don't get the convert2rhel fact the first time during registration , we will get it when the client checks in again ~ 4 hours. Talking with Shim and Jeremy this seems like a fine approach since the systems rhsmcertd will send us the filtered fact again, which is more than enough time before rh_cloud would send off it's report to console.redhat.com
has_convert2rhel = parser.facts.key?('conversions.env.CONVERT2RHEL_THROUGH_FOREMAN') | ||
# Add in custom convert2rhel fact if system was converted using convert2rhel through Katello | ||
# We want the value nil unless the custom fact is present otherwise we get a 0 in the database which if debugging | ||
# might make you think it was converted2rhel but not with satellite, that is why I have the tenary below. | ||
facet = host.subscription_facet || host.build_subscription_facet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You use facet.save unless facet.new_record?
below -- now new_record?
can never be true, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I also do not exactly understand the reasoning for the unless new_record?
-- why didn't we want to store it in the past?
return unless host.subscription_facet # skip method if the host is not a registered host | ||
has_convert2rhel = parser.facts.key?('conversions.env.CONVERT2RHEL_THROUGH_FOREMAN') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would the following also work?
return unless host.subscription_facet # skip method if the host is not a registered host | |
has_convert2rhel = parser.facts.key?('conversions.env.CONVERT2RHEL_THROUGH_FOREMAN') | |
has_convert2rhel = parser.facts.key?('conversions.env.CONVERT2RHEL_THROUGH_FOREMAN') | |
return unless (host.subscription_facet || has_convert2rhel) # skip method if the host is not a registered host |
That'd create the facet if the host has the special fact, and skip otherwise? (If we keep the build_sub_facet
call below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried that in #11110 and ran a pipeline based on the packit build -- it passed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's an interesting thing to think about. AFAIK populate_fields_from_facts
is called for every fact source, so also Puppet. That makes me think the current code will result in unstable values if both RHSM and Puppet are used. Your code to skip if no fact exists is probably more reliable, but also means no mechanism exists to clear the value.
@@ -0,0 +1,9 @@ | |||
class ChangeConvert2RhelToBoolean < ActiveRecord::Migration[6.1] | |||
def up | |||
change_column :katello_subscription_facets, :convert2rhel_through_foreman, :boolean, using: 'convert2rhel_through_foreman::boolean' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
convert2rhel_through_foreman
is a tenary (according to the comment above). It can be nil
if the fact is not present, and 0/1 if the fact is.
Wouldn't converting it to bool
loose that detail? Or can the column still be NULL
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://api.rubyonrails.org/v7.2.0/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-add_column implies it's not specified in the resulting SQL so it's up to the DB implementation. Reading https://www.postgresql.org/docs/current/sql-altertable.html I get the impression the default is to allow NULL
, which also makes sense: adding a column means you either need to provide a default value or allow NULL
values.
I had a closer look at the method and I think some comments in #11110 (review) also apply to the current code and your patch. |
What are the changes introduced in this pull request?
convert2rhel_through_foreman
frominit4
toboolean
build_subscription_facet
because the hosts that come from convert2rhel already are registered and have a subscription facet, so no need to build one which also breaks hosts that are not registered through subscription-managerrhsmcertd
will send us the filtered fact again, which is more than enough time beforerh_cloud
would send off it's report toconsole.redhat.com
https://www.redhat.com/en/blog/converting-centos-rhel-convert2rhel-and-satellite
What are the testing steps for this pull request?
"error": {"message":"Content host must be unregistered before performing this action."}
subscription-manager
installed create a custom fact like sosubscription-manager facts --update
and see if you see the fact in the hostssubscription_facet