On Thu, Nov 2, 2017 at 8:02 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote:
> On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote: > >> 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. >> > > +1 > > 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. >> > > +1 though we could look at creating a CentOS SIG to do it under the sclo > flag. IMHO this can be parallel to the development or even after the fact. > > 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. >> > > +1 > > 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. >> > > +1 > > This would be similar to how we now have koji: as a staging ground, we > test against this and promote if it's stable with the added benefit that > it's easier to consume. > > RPM Signing >> >> I am recommending here that we sign the SCL RPMs with a new GPG key >> generated just for signing the SCL packages. >> > > COPR signs repos by default with its own GPG key. Do you want a separate > GPG key when we host it on yum.theforeman.org? > > 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. >> > > +1 > > 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. >> > > For me this depends. If an ansible playbook is just a list of commands > then IMHO it doesn't add much value over a shell script. If you use higher > level tools (modules?) then there's a great benefit in both readability and > maintainability. I could see us developing a copr module so we can use > copr_build and such. I might have to lay out more of what I am thinking, but based on some other work there is a chunk of neat and powerful stuff that be done by using Ansible + inventories with packages. Plus, as you said, modules give the ability to create some higher level abstractions. I also stand by that Ansible syntax is easier for new contributors than most bash scripts. > > > -- > 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. > -- 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.
