Fixes #36856 - add check for katello-rake task

[m-bucher]

[sbernhard]

I'm ok to remove the data in a later stage but first of all, it should be visible to users that something was wrong. Maybe they want to analyze WHY the association between candlepin and katello broke. For this, they need to have the data in the database; check logs; do the usual steps to analyze a issue. If it would just be cleaned out, there is no way to analyze such an issue. Therefore we wan to introduce one step to check and print the isuse first. Later on, it can be cleaned out.

[jeremylenz]

Maybe they want to analyze WHY the association between candlepin and katello broke. For this, they need to have the data in the database; check logs; do the usual steps to analyze a issue. If it would just be cleaned out, there is no way to analyze such an issue. Therefore we wan to introduce one step to check and print the isuse first. Later on, it can be cleaned out.

This makes sense, thanks. My question then, is if this is the best way to implement it?

As far as I understand (so far), the hosts cleared out during upgrade are those

• with a subscription facet, meaning at one point they were registered; and
• with a subscription facet uuid missing either from Katello or from Candlepin.

That means these hosts are supposed to be registered, but will never work properly as registered hosts because some of their data is gone from Katello or Candlepin.

What is the goal of the check in this case? What are the actions a user should take?

The remedy in this situation is to

a) remove the incomplete data; and b) re-register the host, if the host still actually exists and you want to manage it.

The clean_backend_objects task that runs during upgrade takes care of a) for you. The question is, will most users want that to happen automatically (which is what happens now), or will they want to be warned beforehand so they can do some sleuthing and figure out how it happened? Personally I'm not sure that most users would want the latter. Maybe we go somewhere in the middle and say "We removed orphaned hosts with the following names; you may want to check on them"? Seems too harsh to me to halt the entire upgrade. If you want to be extra-conscientious, can't you just run clean_backend_objects yourself with COMMIT=false before upgrading?

@ehelms @parthaa thoughts?