Katello 4.4.0 GA Release Process

Development Releases
1

Make this post a wiki

Roles

When Ready to Release

Release Owner

  • Request Hammer CLI Katello release from maintainers

  • Request Virt Who Configure release from maintainers

  • Request any other releases as needed from the release owners (consult the :repos: section of configs/katello/4.4.yaml)

  • Change Redmine version 4.4.0 state to Closed

  • Do Cherry-picks: Clone tool_belt

    • If any minor versions of Katello have been added to Redmine since the last cherry-pick, make sure to include them in prior_releases in configs/katello/4.4.yaml
    • Run ./tools.rb setup-environment configs/katello/4.4.yaml
    • Run GITHUB_ACCESS_TOKEN=<secret> ./tools.rb cherry-picks --version 4.4.0 configs/katello/4.4.yaml
    • Open a PR in Katello release branch. Make sure the PR name starts with [CP] to prevent our automations from adding it to Redmine issues.
    • Using git cherry-pick -x as needed, verify tickets in the cherry_picks_4.4.0 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, in repos/katello/4.4.0/katello. This way when you run cherry-picks again, tool_belt will be aware of any picks already completed.
    • For any cherry-picks that are not needed (including Redmine trackers) you can add them to the :ignores: section of tool_belt in configs/katello/4.4.yaml

  • Check for outdated deprecation warnings in the current and next release with ./tools check-deprecation-warnings configs/katello/4.4.yaml. Follow the instructions in the output of the command. Don’t forget to create any Redmine issues needed!

  • Open a PR (or use cherry-pick PR) against the release branch which updates lib/katello/version.rb to 4.4.0:

    • git pull to make sure you have the latest changes
    • sed '/VERSION/ s/".\+"/"4.4.0"/' lib/katello/version.rb
    • Update/add the CHANGELOG.md file: GITHUB_ACCESS_TOKEN=<secret> ./tools changelog configs/katello/4.4.yaml
    • Commit: git commit -m "Release 4.4.0"
    • Ensure that the commit above is the last commit and there are no commits after it. This is the commit that will get tagged. (Rearrange commits with git rebase -i if needed.)

  • Once the PR is merged, perform the following in the Katello release branch (the real one, not your fork):

    • Tag: git tag -s -m "Release 4.4.0" 4.4.0
    • Push: git push --follow-tags (Must be pushed directly to the release branch, as pull request merges will not preserve tags.)
    • Generate source gem: gem build katello.gemspec
    • Ensure you have a working login and password at rubygems.org
    • Push gem: gem push katello-4.4.0.gem

  • Inform the delivery team that the gem is published

Once Source is Available

Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.

Release Engineer

Once release is out

Release Owner

2

I was wondering whether the 4.4 shouldn’t be delayed until the encryption bug in pulpcore 3.16+ has been fixed.

See PulpRpmClient::ApiError HTTP 500 during sync repository

Basically, if you have more than 100 repositories on your main server, it may break the sync. For the content proxy it’s worse, as each repository in each CV and LE is a remote repository and thus it exceeds the 100 even faster…

It breaks during upgrade from pulpcore 3.14 to 3.16 (4.2 to 4.3). PR and repair tool is in the making…

pulpcore issue #2327 and pulpore pr # 2333

3

@gvde thanks for bringing that up. Pulp versions can be bumped up without releasing a new Katello version, so we should be set to keep the release train going. I can add a warning in the release announcement about it. Curious to hear other opinions from @katello, though.

4

Well, I am currently still on 4.2 because of

and those are only those, I know of because I see them on my upgraded test server. I was planning on upgrade to 4.3 once there is a version which allows me to upgrade without errors and manual intervention. I guess, I can forget about getting upgraded without manual workarounds but the last one is a show stopper for me, even although I know how to work around the problem.

It’s my understanding that 4.2 is EOL with the release of 4.4, so that would force people to upgrade to 4.3…

5

I’m going to work on pushing those issues, I want there to at least be plan in motion before we leave 4.2 behind.

1 Like
6

Okay, so:

  1. The fix for the Debian repo error is in 4.4 as a rake task.
  2. The Pulp artifact ownership issue is planned on being fixed in foreman-maintain but in the least it’ll be a documented manual step.
  3. The Pulp repo sync error relating to DB field encryption will be taken care of in the next release of Pulpcore 3.16 (coming very soon), and I am going to personally test it out before making the 4.4.0 GA release announcement. I’ll also make sure the command to run the repair script is in the docs.
1 Like
7

The Pulpcore update with the DB encrypted field fix is merged into packaging, just need to wait until it’s built so I can test. The docs PR with the new troubleshooting steps is being actively reviewed. Once that’s all taken care of, and the 4.4.0 build pipeline passes, I’ll be sending out the release announcement.