At some point in the past, the simp-adapter RPM was created with the primary purpose of downloading the appropriate version of puppet for your system. This spawned two different RPM result sets of simp-adapter-foss and simp-adapter-pe both of which provide simp-adapter so that the underlying RPMs don't have to worry about figuring out which one is required.
...
This was spawned by the conversation started on the initial r10k prototyping work PR.
As a corollary, we should probably take a good hard look at what the RPM is doing in the %post section and determine if this is actually still necessary and/or should be in this RPM instead of in the simp config command or the like.
Options considered
Option 1:
Option 2:
Option 3:
Description
Persist the simp-adapter-foss and simp-adapter-pe installation packages with puppet dependencies.
Push all puppet dependencies down to the individual modules
Push all puppet dependencies into the simp RPM.
Pros and cons
Allows for a two-package installation of the entire stack if your repositories are set up correctly.
Having simp-adapter-pe gets confusing and tends to win in the YUM repos. It should probably be isolated into its own repo if this path continues.
Probably the most accurate mechanism
May allow for a one-package installation with yum install simp
May have to persist a package to version matrix to determine what version of puppet is in what upstream package.
Will probably require a re-roll of all modules with a version bump just for this. (If so, this should wait until after 6.4.0 so that we can get the r10k work completed)
Allows for a one-package installation with yum install simp
Eliminates the possibility of installing individual components via RPM without dragging in the entire stack and reduces the simp RPM relevance as a pure meta-RPM (yes, a lot of the stuff in the %post section already needs to be refactored and/or removed but this would make the problem worse)
Would change a lot of long-held RPM couplings and require the most amount of testing to achieve and should wait until after 6.4.0 if selected.
Estimated cost
Status
colour
Green
title
SMALL
Status
colour
YELLOW
title
MEDIUM
Status
colour
Red
title
HIGH
Option 4:
Option 5:
Option 6:
Description
Add a new RPM whose sole purpose is to pin the version of puppet and puppetserver allowed on the system.
This was the original goal of simp-adapter but, if we split this RPM out and ensure that it only is required from the simp RPM, then users can successfully un-pin all RPMs from the underlying puppet installation by simply removing the RPM.
Remove simp-adapter-pe, making simp-adapter-foss default, and add a simp-adapter-unbounded to allow un-pinned versions of Puppet as stated in Option 4
Remove any requirements for Puppet or Puppetserver and move validation to simp-cli
Pros and Cons
Easily allows users to un-pin from the underlying version of puppet
Does not require a full release of SIMP for compatible version bumps or pinning (we've had to work around broken versions of puppet in the past)
Does not require a re-roll of all modules
Easy to implement
Makes it easy to determine when the system has been purposefully deviated from the tested installation state
Allows users to create a system where versions of puppet can be installed that were not evaluated with the SIMP stack and may cause support difficulties.
All Pluses/Minuses from Option 4, plus:
Allows for a single command install (yum install simp)
Allows Bolt, Ansible, etc.
Still creates user confusion
Testing scenarios we don't currently cover
Don't need to worry about Puppet changes
Can be used with Bolt, Ansible, etc w/o having to add/test new adapters
If people don't read instructions, they could create a broken environment
