Infra/Deployment/Platform Roadmap Status

The last update was nearly two months ago and our migration to discourse allows me to provide a slightly better formatted status on the roadmap. If anyone has any new items that feel need to be added to this list of
items please let me know as I’d like to capture the breadth of our infrastrucre/CI/deployment.

Rails 5.X

Status: Complete
Action Items
  • None
  • Rails 5 SCL has been built. This repository lives on Copr.
  • Foreman, Plugins and Katello have all been rebuilt on Rails 5.1 and nightly repositories have been officially updated with passing builds.
  • Foreman 1.17 and Katello 3.6 are branched and based off of the Rails 5.1 and Ruby 2.4 stack updates

Packaging Automation

Status: green


Jenkins Migration

Status: Blocked

  • None
Action Items
  • Migrate Jenkins master to EL7
  • redirect from HTTP needs adding

Jenkins Job Updates

Status: In Progress

  • Foreman nightly release pipeline job created and in JJB
  • Foreman plugins nightly release pipeline created and has replaced former Foreman plugins release jobs
  • Katello nightly release pipeline created and has replaced former
  • Top level symlink ‘ci’ added to foreman-infra

Action Items

  • Move all jobs into JJB
  • Update jobs to run tests with all plugins installed
  • Update hammer core tests to run tests also for the major plugins (atleast foreman and katello)
  • Add job for running hammer integration tests against live foreman/katello


Q: What is the benefit for this effort?
A: modern approach, more secure, provides more efficient jobs, jobs that
are protected against crashes and restarts

Running Container Stack

Status: In Progress

  • On going work to re-factor tooling and add a PR testing job
  • Updated to latest Openshift 3.7.1
  • Fixes submitted to ansible-container
Action Items
  • 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

Merging katello and foreman installers

Status: red

  • None

Action Items

  • Move all checks/hooks to foreman-installer
  • Add katello modules to foreman-installer Puppetfile
  • Move bin/{foreman-proxy-certs-generate,katello-certs-check} to foreman-installer or foreman-maintain
  • Migrate scenarios
  • Sort out the packaging
  • Add deprecation notices to katello-installer / wipe master branch

Updated yum/debian repository structure

Status: blocked

  • None
Action Items
  • 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

Status: red

  • De-prioritized in favor of packaging automation changes

Action Items

  • Phase 1: Submit builds in paralel - only rubygems and nodejs
  • Phase 2: Submit builds in paralel - foreman-core packages
  • Phase 3: Migrate to Copr

Migration off of Openshift V2

Status: red

  • Redmine – moved to stand alone server and off of Openshift entirely
  • prprocessor – moved to Redmine server
  • etherpad – didn’t get moved off of Openshift V2, is currently dead with no way to recover database from the last two months

Data loss aside, is there a plan to spin this back up somewhere else?

I’ll also add that following a discussion at CfgMgmtCamp on the Redmine upgrade, I think I’m unblocked on the removal of redmine_backlogs. Apparently we only have one thing that uses the API field (@Marek_Hulan is that right?), so I think moving to a custom field and a one-time migration of the data should suffice. I’ll obviously not be looking at this until may however, so if there are concerns, get in touch.

Yes, if I’m not missing anything else, we only use release field from backlogs for tracking version in which the issue was fixes. The version (team marek backlog, sprint 27) is still being set, though not very useful imho. That iirc is core field anyway.

1 Like

In the changelogs we do publish things like *A full list of changes in 1.17.0 is available via [Redmine](* which depends the backlogs plugin. Perhaps we can use a search on the custom field instead.

1 Like

I am generally fine with this shift. The minimum requirements I see needed are:

  • ability to filter issues by a release_id
  • ability to create releases
  • ability to “close” a release (that is, prevent new issues from being put on to it but still make it “visible” from API and UI for inspection and potential re-opening)

OK I’m back and this is fairly high on my list. I’ll spin up a test Redmine without Backlogs and import our DB, and we’ll see what we can make work. If any new requirements have come to light then let me know, but otherwise I’ll work from @ehelms’s list.

TBH, it would be super useful if we could attach an issue to multiple releases - especially when we backport a fix.

Can we do that today? (I.e is that new functionality or something we need to port from Backlogs)

no, just saying that if we are moving away from backlogs might as well look into something that would support that :slight_smile:

Odds are I’m going to see what we can do without plugins to start with - I’ll build the devbox with a public IP so we can test it’s capabilities :slight_smile: