Fixes #36579 - Split the installer into multiple subpackages #9564
Conversation
This creates separate RPMs for each scenario. This allows the user to install just a single scenario and never use the --scenario parameter. Packages created: foreman-installer-scenario-$scenario foreman/katello/foreman-proxy-content scenarios foreman-installer-common Puppet modules, Hiera data and other shared files foreman-installer Transitional package that requires foreman-installer-scenario-foreman for a smooth migration
ekohl
force-pushed
the
rpm/develop-36579-split-installer
branch
from
5575b24
to
7989af7
Compare
|
Before I do the same to Debian packages I'd like some agreement on that this is a good structure. |
| Requires: rubygem(kafo) >= 6.5.0 | ||
| Requires: rubygem(kafo) < 8.0.0 | ||
| Requires: ruby(release) | ||
| # As a migration foreman-installer ensures the foreman scenario is installed |
There was a problem hiding this comment.
Two options/questions:
- Could
foreman-installer-foremanObsoleteforeman-installerand avoid this? - Could
foreman-installerbecome the common package rather than a-commonsub-package?
There was a problem hiding this comment.
I considered that, but I don't think you can do that.
Could
foreman-installer-foremanObsoleteforeman-installerand avoid this?
Perhaps foreman-installer-scenario can have:
Provides: foreman-installer = %{epoch}:%{version}-%release
Obsoletes: foreman-installer < 1:3.8.0-somereleaseAnd that could replace it. I'm never sure so would need to test it out. But I think then we can't have a foreman-installer package.
I just realized we need a similar solution for katello, but there we may need to pull in both katello and foreman-proxy-content scenarios to remain compatible.
Could
foreman-installerbecome the common package rather than a-commonsub-package?
Yes, but then I fear we can't do the migration well. Perhaps we can list them as soft dependencies with Suggests, but I really don't trust that if I'm honest. Especially if we take downstream into account.
@evgeni any more ideas?
There was a problem hiding this comment.
Hard no on "Suggests", that implies the package would work without the "suggested" one, but I don't think the installer will without the common bits ;-)
Can you elaborate more on your fear wrt "foreman-installer" is the "common" package? My brain suggests it should work, but its also partially in PTO mode.
And for me, to recap the plan and whether I understood it correctly:
- new users would just install
foreman-installer-scenario-<thing>and that would make things work as needed - existing foreman users would get
foreman-installer-scenario-foremanand would still not have to pass--scenarioand things will work as before - existing katello users would get
foreman-installer-scenario-katelloANDforeman-installer-scenario-fpc(as we don't know, package wise, what they have deployed) and will have multiple scenarios available as before (but as they already installed, they don't need to pass--scenarioanymore) - existing satellite users (even if not modeled here) would get the same as katello, plus the satellite and capsule scenarios, again, with no behavioral changes.
- then, after a few releases, we can drop those transitional packages (the ones depending on the new
foreman-installer-scenario-<thing>) andObsoletethem with the "right"<thing>package
One thing to consider: I know that we use the "is foreman-installer-katello installed" fact to differentiate between foreman and katello installs in a few places (like LEAPP), so we gotta go hunting for those and update them :)
There was a problem hiding this comment.
new users would just install
foreman-installer-scenario-<thing>and that would make things work as needed
Yes, we will modify the installation instructions. I also hope to introduce foreman-installer-scenario-foreman-proxy to provide a non-content proxy so there would be consistency.
existing foreman users would get
foreman-installer-scenario-foremanand would still not have to pass--scenarioand things will work as before
Correct. I hope to get to a point where dnf upgrade will ensure foreman-installer-scenario-foreman is installed when they now have foreman-installer installed.
existing katello users would get
foreman-installer-scenario-katelloANDforeman-installer-scenario-fpc(as we don't know, package wise, what they have deployed) and will have multiple scenarios available as before (but as they already installed, they don't need to pass--scenarioanymore)
Correct, and because they have foreman-installer installed they will also get foreman-installer-scenario-foreman which they also don't need. Perhaps rich dependencies could help here.
In foreman_maintain we can suggest cleanups by looking at the symlink which scenario is active, but that's not going to work in plain dnf.
existing satellite users (even if not modeled here) would get the same as katello, plus the satellite and capsule scenarios, again, with no behavioral changes.
Correct. As above, satellite-maintain can suggest redundant packages. Though it depends on how much we want to patch downstream. In downstream we have satellite and capsule meta packages which could do the migration as well.
One thing to consider: I know that we use the "is
foreman-installer-katelloinstalled" fact to differentiate between foreman and katello installs in a few places (like LEAPP), so we gotta go hunting for those and update them :)
I don't see it show up in foreman_maintain. As for LEAPP: do we still support that? We don't support skipping over releases and we dropped EL7 a while back so by the time they get here, they should already be on EL8.
There was a problem hiding this comment.
I was thinking ahead when we will do LEAPP for 8 to 9, reusing the code :)
There was a problem hiding this comment.
Correct. As above,
satellite-maintaincan suggest redundant packages. Though it depends on how much we want to patch downstream. In downstream we havesatelliteandcapsulemeta packages which could do the migration as well.
My thinking basically, the fact Satellite has meta packages to represent each type means they can require the respective scenario package and do the cleanup.
In all cases, we will know what scenario is installed on the system, and can use that information to do cleanup. We could consider using this as the same opportunity to move the answer files (theforeman/foreman-installer#698) but that might be scope creep. Figured I'd throw it out there as this new packaging provides an opportunity to signal other changes.
There was a problem hiding this comment.
In all cases, we will know what scenario is installed on the system, and can use that information to do cleanup. We could consider using this as the same opportunity to move the answer files (theforeman/foreman-installer#698) but that might be scope creep. Figured I'd throw it out there as this new packaging provides an opportunity to signal other changes.
It is something I also thought about. I mostly worry about the additional tooling that reads it, such as foreman_maintain. Perhaps we should provide a way to output the answers, like some script or some installer output option.
| Requires: rubygem(kafo) < 8.0.0 | ||
| Requires: ruby(release) | ||
| # As a migration foreman-installer ensures the foreman scenario is installed | ||
| Requires: %{name}-scenario-foreman = %{epoch}:%{version}-%{release} |
There was a problem hiding this comment.
| Requires: %{name}-scenario-foreman = %{epoch}:%{version}-%{release} | |
| Requires: (%{name}-scenario-foreman = %{epoch}:%{version}-%{release} unless (%{name}-katello or %{name}-scenario-katello or %{name}-scenario-foreman-proxy-content)) |
I think this should allow users to not get the foreman scenario if they already have something katello-ish
| Requires: foreman-installer-scenario-katello = %{epoch}:%{version}-%{release} | ||
| Requires: foreman-installer-scenario-foreman-proxy-content = %{epoch}:%{version}-%{release} |
There was a problem hiding this comment.
| Requires: foreman-installer-scenario-katello = %{epoch}:%{version}-%{release} | |
| Requires: foreman-installer-scenario-foreman-proxy-content = %{epoch}:%{version}-%{release} | |
| Requires: (foreman-installer-scenario-katello = %{epoch}:%{version}-%{release} unless foreman-installer-scenario-foreman-proxy-content) | |
| Requires: (foreman-installer-scenario-foreman-proxy-content = %{epoch}:%{version}-%{release} unless foreman-installer-scenario-katello) |
but I am not sure those two would cancel themself out and you'd end with a weird result?
| %{configdir}/foreman.migrations | ||
| %config(noreplace) %attr(600, root, root) %{scenariodir}/foreman.yaml | ||
| %config(noreplace) %attr(600, root, root) %{scenariodir}/foreman-answers.yaml | ||
| %config(noreplace) %{scenariodir}/foreman-migrations-applied | ||
| %{parser_cache}/foreman.yaml |
There was a problem hiding this comment.
this could become a macro files_for_scenario(name), but not sure if that'd be over-optimization or not
There was a problem hiding this comment.
I tried to write a macro but couldn't make it work. There's a good chance that's on my side but RPM documentation was insufficient.
|
You asked for Debian… I think there the situation is a tad easier. Given we have no Katello/FPC there, and there is no standalone-proxy scenario today, we can rather safely split things up into |
This creates separate RPMs for each scenario. This allows the user to install just a single scenario and never use the --scenario parameter.
Packages created:
foreman/katello/foreman-proxy-content scenarios
Puppet modules, Hiera data and other shared files
Transitional package that requires foreman-installer-scenario-foreman for a smooth migration
Split off from #8814 and requires theforeman/foreman-installer#870