Hide Forgot
Description of problem: satellite package has dependencies which installs plugins like discovery. If discovery is not enabled in installer, custom installation logic is missing even though user can see plugin being installed in UI. Version-Release number of selected component (if applicable): satellite-6.2.0-6.1.beta.el7sat.noarch How reproducible: always Steps to Reproduce: 1. yum install satellite 2. rpm -q tfm-rubygem-foreman_discovery-5.0.0.3-1.el7sat.noarch 3. Actual results: tfm-rubygem-foreman_discovery-5.0.0.3-1.el7sat.noarch Expected results: package is not installed Additional info:
Proposing this as a blocker, as it can lead to issues when upgradnig from 6.1, such as https://github.com/theforeman/foreman_discovery/pull/268 The problem here is, some old migrations have issues of touching active record objects when migrating data. The first migration is run as part of postrans phase in the spec: https://github.com/theforeman/foreman-packaging/blob/rpm/1.11/foreman/foreman.spec#L771 The presence of additional plugins as the package dependency increases a chance of the migration to fail, because some code is relying on migrations that have not happened yet. A workaround would be to uninstall the plugin first, migrate and then install again, with the installer. But since we have the plugins as dependencies in the main package, it makes it look like one is uninstalling the whole satellite.
The corresponding merge request: https://gitlab.sat.lab.tlv.redhat.com/satellite6/satellite-packaging/merge_requests/16
Copy of my gitlab comment: I don't understand how this solves the situation. It only postpones it a bit as when user executes our installer with --enable-plugin-xyz our installer will (IIUC) make the initial migration with all the listed plugins installed. And we have this in our documentation to do that.
When you enable plugin xyz, then also custom puppet code that configures the xyz plugin is run and does the full plugin installation.
It helps also with the migration a bit, because the first migration happens at `yum update` phase, where the remote execution (and other plugins that might collide with some old migration using active records for data manipulation), and then the rest of migrations of plugins (that usually don't do the data manipulation and are therefore safer to run) happen in separate run. Long story short - you would not hit the migration issues with remote execution, because the migration would happen before. It also give us more space for workaround temporarily uninstalling some plugins.
VERIFIED. satellite-6.2.0-9.0.beta.el7sat.noarch REPRO: # rpm -qR satellite | grep foreman_discovery tfm-rubygem(foreman_discovery) # rpm -q --whatrequires 'tfm-rubygem(foreman_discovery)' satellite-6.2.0-8.2.beta.el7sat.noarch vs. FIX: # rpm -qR satellite | grep foreman_discovery <emtpy> # rpm -q --whatrequires 'tfm-rubygem(foreman_discovery)' no package requires tfm-rubygem(foreman_discovery)
Also OSCAP packages no longer get installed along with installation of satellite package. this package tfm-rubygem-foreman_openscap-0.5.3.4-1.el7sat.noarch was not installed. rpm -q --whatrequires tfm-rubygem-foreman_openscap no package requires tfm-rubygem-foreman_openscap
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1501