Fixes #28656 - Store DMI UUID on Subscription Facet

[jturel]

Not so long ago the DMI UUID (reported by subman) of Content Hosts became critical to the registration process in order to block duplicate host registrations. The value is stored among the system facts, and looking up duplicates at registration time in a very large table can become slow as the number of hosts grow.

This PR helps alleviate the problem by making the DMI UUID a value on the SubscriptionFacet model. The below performance measures are taken from 1000 content hosts each with a distinct DMI UUID fact.

Old query performance

irb(main):002:0> Benchmark.bm do |x|
irb(main):003:1* x.report { 10000.times do; Katello::RegistrationManager.find_existing_hosts('flood0', SecureRandom.uuid); end }
irb(main):004:1> end
       user     system      total        real
   9.863411   0.338413  10.201824 ( 12.369747)
=> [#<Benchmark::Tms:0x000000000d5b16b8 @label="", @real=12.369746921118349, @cstime=0.0, @cutime=0.0, @stime=0.33841299999999985, @utime=9.863411000000001, @total=10.201824>]

New query performance:

irb(main):004:0> Benchmark.bm do |x|
irb(main):005:1* x.report { 10000.times do; Katello::RegistrationManager.find_existing_hosts('flood0', SecureRandom.uuid); end }
irb(main):006:1> end
       user     system      total        real
   1.884269   0.014484   1.898753 (  1.904810)

Looks like the duplicate lookup is 5x faster.

To test

• checkout PR

• migrate the DB

• run the rake task to populate subscription facet: bundle exec rake katello:upgrades:3.15:set_sub_facet_dmi_uuid

• Registrations should exhibit all of the same behaviors w.r.t preventing duplicate hosts by DMI UUID.

• Changing the DMI UUID from the client side via fact override should also update the subscription facet field

[theforeman-bot]

Issues: #28656

[jturel]

This test case is irrelevant b/c facts are now destroyed during unregister

[jturel]

I don't mind reverting this, but thought it was simple enough to include. Changed to delete_all since we aren't concerned with the values that are destroyed

[parthaa]

Couple of things

• I am not sure why you chose a rake task to upgrade instead of seeding from the migration automatically? This would make sense if I am talking to a service like candlepin, but this is purely copying an attribute right?
• Might need to add the rake task to https://github.com/Katello/katello/blob/master/db/seeds.d/111-upgrade_tasks.rb

[jturel]

Couple of things

• I am not sure why you chose a rake task to upgrade instead of seeding from the migration automatically? This would make sense if I am talking to a service like candlepin, but this is purely copying an attribute right?

Fair point but I want to find some examples to make sure that's what we typically do before moving it to the migration

• Might need to add the rake task to https://github.com/Katello/katello/blob/master/db/seeds.d/111-upgrade_tasks.rb

+1 (if we don't move to the migration)

[parthaa]

Fair point but I want to find some examples to make sure that's what we typically do before moving it to the migration

https://github.com/Katello/katello/blob/master/db/migrate/20150930183738_migrate_content_hosts.rb

[parthaa]

Sounds like separate rake task is more beneficial longer term. Just add a test for that rake task

[jturel]

@parthaa updated!

[parthaa]

I liked the performance improvements, almost 8 times faster for me. ACK

[jturel]

[test katello]