In a previous thread , we discussed building an SCL vs. vendorizing gems
and the general consensus was to build an SCL. This thread is to outline a
starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
appreciate comments towards this design.
I'll begin by laying out some overall goals for the effort, a general
proposal of information and finally a breakdown of the why for each of the
proposal items to better explain my thinking.
- Stand alone Rails 5.1 SCL and repository
- Owned and maintained by the Foreman community
- Easy to update and maintain
- Strive for automation and package tooling to reduce maintenance cost
Build location: Copr
SCL Name: tfm-ror51
Git repository: theforeman/tfm-ror51-packaging
RPM Signing: signed by unique Foreman owned GPG key
Tooling Repo: create package tooling repository separate from
Tooling Technology: Ansible
There has been discussion around moving our RPM builds to Copr and off of
Koji. This will require shifting our configuration and setup, testing and
working out kinks in Copr workflow. Building this Rails SCL provides us an
opportunity to use Copr from the start, get familiar with it and workout
tooling to interact with and manage a repository there. Therefore, I am
proposing to start with Copr from the get go and avoid Koji.
Given the Foreman community will own the SCL, and our SCL namespace is
'tfm' I am suggesting we follow convention by naming it tfm-ror51. Previous
Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.
I am proposing we don't put this into foreman-packaging given the lifecycle
of the SCL will not follow that of Foreman. Further, with the goal to
create a stand-alone Rails SCL repository this should have its own
We could point at the direct Copr repository, and reduce our bandwidth.
However, since we own this Rails SCL I believe we should host it as such
officially. Further, this would allow us to do some pre-flight testing by
building a repository in Copr, running a test of either the SCL itself
and/or Foreman against the SCL updates before promoting.
I am recommending here that we sign the SCL RPMs with a new GPG key
generated just for signing the SCL packages.
With an eye towards foreman-packaging changes, I am proposing we create a
separate git repository for all package tooling. The goal here would to
build out new tooling to allow easier maintenance of the packaging and
repository. This will allow the tooling to evolve independently of either
packaging repository. Further, when applying this tooling to
foreman-packaging later, the tooling would not have to be duplicated across
I am proposing a centralization on Ansible as the tooling technology for a
number of reasons. First, I feel that it has a low barrier to entry while
providing a mix of high and low level interfaces. Secondly, Ansible allows
orchestrating and building out more complex and directed tasks. Third, a
team of us has some built out Ansible tooling that has been working well
for us in another area that would be easy to port for packaging management.
I personally think bash is complex to understand for complex actions and is
too simple for building up a set of cohesive tooling.