Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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
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:
DescriptionPersist the simp-adapter-foss and simp-adapter-pe installation packages with puppet dependencies.Push all puppet dependencies down to the individual modulesPush all puppet dependencies into the simp RPM.
Pros and cons

(plus) Allows for a two-package installation of the entire stack if your repositories are set up correctly.

(minus) 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.

(plus) Probably the most accurate mechanism

(plus) May allow for a one-package installation with yum install simp

(minus) May have to persist a package to version matrix to determine what version of puppet is in what upstream package.

(minus) 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)

(plus) Allows for a one-package installation with yum install simp

(minus) 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)

(minus) 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:
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.

Pros and Cons

(plus) Easily allows users to un-pin from the underlying version of puppet

(plus) 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)

(plus) Does not require a re-roll of all modules

(plus) Easy to implement

(minus) 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.

Estimated costSMALL

Action items

  •  

Outcome

  • No labels