This has been out for about a week with some comments and discussion so far on the etherpad. I want to give a round of mention and discussion via -dev list as well since sometimes etherpad is not obvious for updates. I have copied the etherpad here. I will leave this thread open for around a week, at which point, based on discussions that have occurred, take this and copy it out to a more stable location and begin to give updates routinely on these items over time.
High Level Needs - Rails 5.X - need rh-ror50 or custom built SCL - consider whether we introduce a new SCL (e.g. tfm-ruby23) to separate RPMs built against old SCL vs. new - comment mmoll: We would need to upgrade Ruby (to 2.4 or 2.5) later, but I'd expect Rails 5.0 and even 5.1 to fully work also on Ruby 2.2 - commend ekohl: if package names remained equal then it would simplify the installer/docs - should we jump to 5.1.latest and build the SCL instead? rh-ror50 is the last Rails SCL from RHSCL team - comment mmoll: with a little help from core and plugin devs, a move to Rails 5.1 for 1.17 feels achievable. - dlobatog: +1 - introducing the SCL to retire it quite soon will be a pain for upgrades and 5.1 for 1.17 doesn't seem that far off. - Jenkins Migration - Migrate Jenkins master to EL7 - add https interface to Jenkins - Jenkins Job Updates - Migrate jobs to pipelines - What is the benefit for this effort? - modern approach, more secure, provides more efficient jobs, jobs that are protected against crashes and restarts - Move all jobs into JJB - Update JJB code location within git for discoverability - Update jobs to run tests with all plugins installed - Update hammer core tests to run tests also for the major plugins (at least foreman and katello) - Add job for running hammer integration tests against live foreman/katello - Running Container Stack - address Github issues created from initial merge - remove current hacks in deployment - build up test suite for verifying container stack - add Jenkins job to build containers nightly - find way to continuously test container deployment - Merging katello-packaging to foreman-packaging - develop and agree on strategy for moving packages - move packages - any chance of moving Katello tags into foreman-plugins directly? - yes, but we need to solve other problems first: - updated yum repository structure (see below) - individual package release pipelines - Release automation - Using tool_belt & foreman_release to do the cherry_picking/tagging/building/signing automatically - Update http://projects.theforeman.org/projects/foreman/wiki/Release_Process to document how it should work - Moving Katello puppet modules to foreman - move modules to theforeman Organization - add puppet modules to foreman-installer-modulesync - Merging katello and foreman installers - Move all checks/hooks - Add katello modules - Move bin/{foreman-proxy-certs-generate,katello-certs-check} - Migrate scenarios - Sort out the packaging - Add deprecation notices to katello-installer / wipe master branch - Updated yum repository structure - Email thread discussing re-structure of repositories - agree on layout - re-factor mash scripts for new deployment - re-factor sync scripts to yum/deb repositories - update foreman release RPM for new repositories - Move package building from Koji to Copr - Phase 1: Submit builds in paralel - only rubygems and nodejs - Phase 2: Submit builds in paralel - foreman-core packages - Phase 3: Migrate to Copr - Multi-server service deployment - Migration off of Openshift V2 - Redmine - prprocessor - etherpad On Tue, Sep 19, 2017 at 8:24 AM, Eric D Helms <ericdhe...@gmail.com> wrote: > > > On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe <greg.sutcli...@gmail.com> > wrote: > >> So, +1 to this idea, we've been lacking in direction for a bit, and a >> "community roadmap" has been on my agenda for a while. Whilst that's >> not 1:1 the same as what you're saying, it's related, and planning is a >> good idea. >> >> On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote: >> > >> > [1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap >> >> Two things - firstly, isn't this hosted on Openshift v2, which is going >> away soon? Secondly, are you aware of http://projects.theforeman.org/pr >> ojects/foreman/wiki/Infrastructure_Updates >> <http://projects.theforeman.org/projects/foreman/wiki/Infrastructure_Updates> >> on the wiki? >> > > First, yep which I mentioned in the thread related to Openshift V2 > migrations. Second, I am aware of that as thats where I got some of the > items in the list. When this is all said and done, I can move it to the > wiki (or somewhere else) but the wiki is not a great platform for comments > and building up a discussion. > > >> >> Combining those two points, would it be better to have this in the wiki >> rather than on an etherpad? >> >> From my side, I'm working with Michael on upgrading the Puppet/Foreman >> infra, and with Evgeni on migrating/upgrading Redmine. I don't think >> either of these is controversial, but it's out there for the record ;) >> >> Greg >> >> -- >> 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 > -- 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.
