...
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 | Probably the most accurate mechanism May allow for a one-package installation with 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 | Allows for a one-package installation with Eliminates the possibility of installing individual components via RPM without dragging in the entire stack and reduces the 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 |
|
|
|
Option 4: | |||||||||
---|---|---|---|---|---|---|---|---|---|
Description | Add a new RPM whose sole purpose is to pin the version of This was the original goal of | ||||||||
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 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. | ||||||||
Estimated cost |
|