Building an Infra/Deployment/Platform Roadmap

Howdy All,

We've recently had some discussions about infra changes, past discussions
about deployment projects and additions (e.g. containers) and platform
changes (e.g. Rails 5.X support). For me, these all live in a similar area
of functionality or at the very least similar area of how they affect the
overall project and its constituents. Further, infra, deployment and
platform changes tend to be involved with wide ranging affects across core,
plugins, testing and infrastructure. To that end, I'd like to build up a
Roadmap of items that fall into these categories and working list of
mid-level tasks that must be examined or completed in order to achieve them.

I've started a list of these pulled from discussions that have happened on
the mailing list, IRC or in PR discussions and put them into the etherpad
[1]. I'd like to ask for comments on existing, additional tasks, questions
or concerns, and other items that fit the theme of the discussion to be
added to the etherpad.

After some amount of gathering, editing and initial discussion, I plan to
post the list to the mailing list for any further discussion and then
finalizing it as the "current" Roadmap for items within it with some sense
of priority and timing for each. With the goal being to keep it up to date
over time so that we are continuing to track and provide visibility in
these areas.

[1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap

··· -- Eric D. Helms Red Hat Engineering

I filled in the "Merging katello and foreman installers" section since I
already started the work.

I started to replace checks/disk_size.rb1 and
hooks/pre/17-memory_check.rb2 but others I still need to investigate.

For example there's pre/10-reset_feature.rb3 in katello which is a lot
like pre/10-reset_foreman_db.rb4.

pre_validations/11-check_proxy_url.rb6 is already handled in
puppet-katello7 with Puppet 4 types.

Other things might be simplified by extending kafo. There's a lot of
duplication in the katello hooks, like the broken exit function8 meant
you had to use kafo.class.exit() rather than exit(). Some helpers could
also be moved in the library itself.

All in all this might be larger than I initially suspected but we'll get
there.

··· On Mon, Sep 18, 2017 at 11:21:04AM -0400, Eric D Helms wrote: >Howdy All, > >We've recently had some discussions about infra changes, past discussions >about deployment projects and additions (e.g. containers) and platform >changes (e.g. Rails 5.X support). For me, these all live in a similar area >of functionality or at the very least similar area of how they affect the >overall project and its constituents. Further, infra, deployment and >platform changes tend to be involved with wide ranging affects across core, >plugins, testing and infrastructure. To that end, I'd like to build up a >Roadmap of items that fall into these categories and working list of >mid-level tasks that must be examined or completed in order to achieve them. > >I've started a list of these pulled from discussions that have happened on >the mailing list, IRC or in PR discussions and put them into the etherpad >[1]. I'd like to ask for comments on existing, additional tasks, questions >or concerns, and other items that fit the theme of the discussion to be >added to the etherpad. > >After some amount of gathering, editing and initial discussion, I plan to >post the list to the mailing list for any further discussion and then >finalizing it as the "current" Roadmap for items within it with some sense >of priority and timing for each. With the goal being to keep it up to date >over time so that we are continuing to track and provide visibility in >these areas. > > >[1] http://pad-katello.rhcloud.com/p/infra-deployment-roadmap

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.

>
> [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 on the wiki?

Combining those two points, would it be better to have this in the wiki
rather than on an etherpad?

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 :wink:

Greg

··· On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote: From my side, I'm working with Michael on upgrading the Puppet/Foreman

> 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.
>
> >
> > [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 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.

··· On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe wrote: > On Mon, 2017-09-18 at 11:21 -0400, Eric D Helms wrote:

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 :wink:

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Eric D. Helms
Red Hat Engineering

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
    Release Process - Foreman 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 wrote:

On Tue, Sep 19, 2017 at 5:10 AM, Greg Sutcliffe greg.sutcliffe@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 :wink:

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Eric D. Helms
Red Hat Engineering


Eric D. Helms
Red Hat Engineering