Foreman 1.18 Release

Development
1

Hi,
this is just an early warning that develop branch for 1.18 is scheduled to branch in 1 month.

This time, I’ll try to contain information regarding 1.18 in a single thread rather than creating a new one for each announcement. This experiment aims to make it easier for people to follow the current release status as they will need to watch only one thread. If we find out that it does not work because the discussion gets too branched out, we can always create new threads.

O.

5 Likes
2

I wanted to look at what our current support stack is, proposed changes and if there is anything we want to update for 1.18. Experts in these areas, please post corrections. I plan to keep this post “pinned” and updated as we evolve changes.

Current Stack
  • Operating Systems
    • EL7
    • Debian Stretch
    • Ubuntu Xenial
  • Ruby
    • Ruby 2.4 (EL7)
    • Ruby 2.0 (base RHEL) (installer & smart proxy)
    • Ruby 2.3 (Xenial)
    • Ruby 2.3 (Stretch)
  • Common
    • Rails 5.1.4
    • Puppet 5 (default)
    • Puppet 4
  • Databases
    • Postgres
      • 9.2 (EL7)
      • 9.5 (Xenial)
      • 9.6 (Stretch)
    • MySQL
      • 5.5.6 (EL7)
      • 5.6 (Xenial)
      • 5.5.9 (Stretch)
  • Katello
    • Pulp 2.15
    • MongoDB 2.6
    • Candlepin 2.1
    • Qpid 1.36
    • Qpid Router 1.0

Client Support

  • Puppet
    • Any
  • Provisioning
    • ?
  • Katello
    • EL5 (katello-host-tools only, no agent support)
    • EL6
    • EL7
    • Fedora 26
    • Fedora 27
Proposed Updates
  • Katello
    • MongoDB 3.4 from SCL
  • Common
    • Rails 5.1.5
3

This was bumped to 1.0 in EPEL (and needed fixes backported to older katello versions).

1 Like
4

This is correct, and the new katello-host-tools should actually work properly on fedora 26/27

5

Hi,
this is just a quick reminder that 1.18 is scheduled to branch in 2 weeks.

6

Thanks Ondrej, would it make sense to define 1.18.0 milestone at github so that we can mark PR that are considered release blockers? That should help with awareness and prioritization during reviews.

7

Yes, I think that is reasonable.

8

Update of the current status:

  • We need to resolve js build error in nightlies as already mentined in different thread. Could someone from @ui_ux take a look please? Would removing source maps for production be a viable option?

  • MTU for subnet is close to being merged. Though it is not a blocker, it would be nice if we could have it in 1.18.

  • Fix for compute attributes is a blocker and should go into both 1.17 and 1.18 as it is related to Rails 5.

  • installer needs changes to support new foreman_ansible features

1 Like
9

I think we can just merge the PR now. I just have a small question regarding one test left. But the tests pass and it’s not a problem.
I’ll just hit the button.

Timo

10

I am actively working on building an update to the Rails 5.1 SCL for Rails 5.1.6. Is that considered a branching blocker?

11

Does this imply the branch date is moving due to these issues? If yes, can we set a new target date based on estimation to fix them? That will just help with planning even if it moves again rather than having a “as soon as possible” tactic.

12

I would not consider the SCL update a blocker for branching. I would prefer moving forward when we can.

If we manage to solve everything today, we will not have to postpone branching ;-). I could set a new date, but that would be kind of random, because I have no estimation on how long it will take to fix these issues.

  • fix for compute attributes is ready and can go in today if it gets ack from a reviewer

  • @ekohl is trying to do a scratch build without source maps to address the js issue

  • I found out about ansible stuff just yesterday and I am not sure what is needed there, maybe @dLobatog knows?

13

We’ve merged the PRs needed for this:

https://github.com/theforeman/foreman-packaging/pull/2348
https://github.com/theforeman/puppet-foreman_proxy/pull/415

I’ll have a look at the Debian side of it and we need to verify if our backup tooling also backs up /var/lib/foreman-proxy. The benefit is that we no longer need to consider /usr/share/foreman-proxy writeable. Since we also modified the REX SSH plugin, I’m also going to verify that still works.

This should no longer be considered a blocker for branching.

14

This one was merged few moments ago too.

I started looking into this. I think we should fix more instances of the same problem but I expect to have it ready during today/tomorrow.

15

I have a fix for report metrics:

https://github.com/theforeman/foreman/pull/5408

16

The current blocker in nightlies is that we need a new smart_proxy_dynflow_core release that’s compatible with dynflow 1.0.0.

17

smart_proxy_dynflow_core-0.2.0 was just released and pushed into rubygems and packaging PRs are opened

18

That’s merged, but could you also do a release of smart_proxy_dynflow? They’re tightly coupled and need to be the same version.

19

With that done, there’s now only

  • foreman_ansible needs dynfow < 0.9 while 1.0.0 is packaged
  • smart_proxy_remote_execution_ssh needs smart_proxy_dynflow < 0.2 while 0.2.0 is packaged
20

I’ve just announced Katello 3.7 branching[1] and wanted to cross-link these posts since we are basing on Foreman 1.18

Please update [1] if there are going to be any Foreman changes that will affect us.

[1] Katello 3.7 branching in 2 weeks