Run rpm-datarepair 4007 on upgrade

[qcjames53]

Add a call to run pulpcore-manager rpm-datarepair 4007 as a component of the rpm_datarepair procedure, which will convert certain empty strings in the pulp DB to null values. Added that procedure to the satellite_upgrade scenario.

Considerations

pulp_rpm 1263 added rpm-datarepair 4007 as a valid operation; it's being backported to 3.27, 3.29, 3.32, and 3.35. However, I don't think I can guarantee users will have the correct Z version of pulp-rpm installed. I made this fail gracefully, with a small message indicating the 4007 call was skipped / unsuccessful. I am unable to have the rpm_datarepair procedure fail regularly, as is it is a component of the sat upgrade. I would rather this at least output a message to stdout. Does my approach look reasonable?

Testing steps

Upgrade Pulp and the Pulp dependencies to Pulp 3.105

We need at least pulpcore 3.105 and pulp-rpm 3.35.2 for the 4007 fix to be packaged. If you need any help with this, please let me know. I can always send you a VM snapshot.

1. We need python 3.12 (centos9 ships with 3.9 by default). Run sudo dnf config-manager --set-enabled crb, sudo dnf install -y python3.12 python3.12-pip python3.12-devel, and python3.12 --version to verify.
2. Install the new pulpcore and pulp plugin versions from PyPi using pip:

sudo python3.12 -m pip install --upgrade --force-reinstall \
   pulpcore==3.105.0 \
   pulp-ansible==0.29.5 \
   pulp-container==2.27.2 \
   pulp-deb==3.8.1 \
   pulp-rpm==3.35.2 \
   pulp-python==3.26.1 \
   pulp-ostree==2.6.0

Note pulp-ostree required these dependencies for me: sudo dnf install -y cairo-devel gobject-introspection-devel cairo-gobject-devel.
Note: I also needed to run sudo python3.12 -m pip install psycopg2-binary.
3. Edit /etc/systemd/system/pulpcore-api.service - Change to:
ExecStart=/usr/local/bin/pulpcore-api
4. Edit /etc/systemd/system/pulpcore-content.service - Change to:
ExecStart=/usr/local/bin/pulpcore-content
5. Edit /etc/systemd/system/pulpcore-worker@.service - Change to:
ExecStart=/usr/local/bin/pulpcore-worker
6. I had to upgrade postgresql with the following steps (might not be required for you):

sudo dnf module enable postgresql:15 -y
sudo dnf install -y postgresql-server postgresql-contrib postgresql-upgrade
sudo systemctl stop postgresql pulpcore*
/var/lib/pgsql/data/postgresql.conf - Commented out data_directory setting
sudo postgresql-setup --upgrade
sudo systemctl start postgresql
sudo -u postgres psql -c "SELECT version();" # Verify version
sudo -u postgres psql -l # Verify DBs migrated
sudo -u postgres reindexdb --all
/var/lib/pgsql/data/pg_hba.conf - Changed auth from peer/ident → trust
sudo systemctl reload postgresql
sudo ausearch -m AVC -ts recent 2>/dev/null | grep pulpcore-api.sock | audit2allow -M pulpcore_httpd
sudo semodule -i pulpcore_httpd.pp

7. sudo systemctl daemon-reload
8. sudo systemctl restart pulpcore* --all
9. Run pulp migrations with sudo -u pulp PULP_SETTINGS='/etc/pulp/settings.py' DJANGO_SETTINGS_MODULE='pulpcore.app.settings' /usr/local/bin/pulpcore-manager migrate
10. Check the correct pulp plugin versions are running with sudo pulp status.
11. Clone foreman_maintain.

Testing this PR

1. Check out this PR.
2. In lib/foreman_maintain/concerns/pulp_common.rb, modify pulpcore_manager to look like this:

      def pulpcore_manager(command)
        # Prefer /usr/local/bin if it exists (pip installation), otherwise use system path
        manager_bin = File.exist?('/usr/local/bin/pulpcore-manager') ? '/usr/local/bin/pulpcore-manager' : 'pulpcore-manager'
        "PULP_SETTINGS=/etc/pulp/settings.py DJANGO_SETTINGS_MODULE=pulpcore.app.settings runuser -u pulp -- #{manager_bin} #{command}"
      end

3. Run sudo bundle exec foreman-maintain advanced procedure run pulpcore-rpm-datarepair to test the changes.
4. Validate the unit tests (2) are appropriate.
5. If you really want to spend a lot of time on this, run a full satellite upgrade to validate the satellite_upgrade scenario addition.

[ianballou]

I haven't tested it but it's generally looking solid. One comment about the existing data repair command.

[ianballou]

+1 to checking if the script exists since it's not RPM packaged yet.

[pavanshekar]

Hi @qcjames53! I tested this PR and the functionality works correctly. Successfully fixes repositories with empty package_signing_fingerprint and gracefully handles when commands are unavailable.

I have one comment about the placement in the upgrade scenario.

[pavanshekar]

Thanks for making the changes! Works well 👍

[ianballou]

Thanks!