In a previous thread [1], 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. Goals * 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 Proposal Build location: Copr SCL Name: tfm-ror51 Git repository: theforeman/tfm-ror51-packaging Hosted: yum.theforeman.org/rails/tfm-ror51 RPM Signing: signed by unique Foreman owned GPG key Tooling Repo: create package tooling repository separate from tfm-ror51-packaging repo Tooling Technology: Ansible Breakdown Build Location 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. SCL Name 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. Git Repository 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 lifecycle. Hosted 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. RPM Signing I am recommending here that we sign the SCL RPMs with a new GPG key generated just for signing the SCL packages. Tooling 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 branches. Tooling Technology 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. -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
