Where should the requirement for Puppet and/or PE be housed in the SIMP RPM stack?

Add your comments directly to the page. Include links to any relevant research, data, or feedback.

Status	IN PROGRESS
Impact	LOW
Driver	Trevor Vaughan
Approver
Contributors	Dylan Cochran (Unlicensed) Liz Nemsick Judith Johnson Nick Markowski Nick Miller Jeanne Greulich Chris Tessmer Michael Morrone Michael Riddle Brandon Riden (Unlicensed)
Informed
Due date	22 Mar 2019
Outcome

Background

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.

As time progressed, this also became the focal point for 'common RPM materials' such as the (infamous) post-installation script that would copy files from where the RPM dropped them into the location that puppet expected.

When this was originally written, there were name changes on the puppet RPM front quite often and things were tremendously in flux. Since then, things have pretty much stabilized and we may be able to remove the strict requirement on PE components with guidance that the user needs to install them manually prior to SIMP installation. This would take away one 'easy button' but may make things easier to maintain over time.

Relevant data

The r10k materials are currently being added to simp-adapter since it is still the nexus of common RPM scripts and materials.

In general, users still want an "easy button" to installing the whole stack and we need to carefully pin versions. Additionally, the simp RPM is not a requirement for anything and has been designed as a strict meta-RPM for ease of use. The adapter took on the hard work for environments that wish to have a partial SIMP installation based around the RPM sets. This is completely valid, but may not be able to be fully supported. At this point though, we should be able to extract the supported puppet versions from the modules metadata.json if we haven't started already.

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

SMALL

MEDIUM

HIGH

Option 4:

Option 5:

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

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