#7032 Recent openQA requires postgres 9.5, but QA db server is on 9.2
Closed: Fixed 5 years ago Opened 5 years ago by adamwill.

I recently tried to upgrade the staging openQA instance to a recent upstream release. However, it failed to work, as it turns out openQA now requires its database to be running at least postgresql 9.5, but the QA database server (which we're using for the openQA databases) is running an older version (I believe 9.2, on RHEL 7).

I've looked into the dependency, and it's genuine - openQA is now using Mojolicious::Plugin::Minion, an aysnc task system provided by its framework (Mojolicious), and that really does use features that are only in postgresql 9.5+. Previously openQA used a kind of custom fork of Minion which didn't have those features, but upstream had no reason to maintain it any longer.

We don't really have an option to stick with older openQA as there just isn't any meaningful development / support for older releases, to be able to work reasonably together with upstream we need to update to new versions quite regularly.

So, we really kinda need to make 9.5 (at least) available to the openQA servers somehow. Options that have come up so far:

  • Keep the QA DB server on RHEL 7 and keep using it, but get a newer postgres from an SCL, either 9.5 or 9.6
  • Keep using the QA DB server but switch it over to Fedora, to get a newer postgres that way
  • Split the openQA databases off to a separate server instance with RHEL 7 + SCL or Fedora, leave Taskotron etc. on postgres 9.2 on the existing server

Tagging relevant folks, @tflink @kevin @jskladan - thoughts? Thanks!


I would strongly vote for moving the QA DB server to Fedora.

I'd be in favor of making a new fedora qa db server, then migrating things to it from the rhel one until we can retire that one. That should allow openqa to use it now, and the other things to move when they can (to save a flag day). But we could do a flag day too if people strongly prefer that.

I do not want to use SCLs for a number of reasons.

OK, let's hear @jskladan 's $0.02 before picking a choice. We've reverted openQA staging to the old code and a db backup for now so things are working again, we have time to make a choice here.

I don't really have any preference. So, I trust @kevin to know what's best.

@kevin 's plan sounds fine to me also.

I'll spin up a new qa-db03 soon.

Metadata Update from @kevin:
- Issue assigned to kevin
- Issue priority set to: Waiting on Assignee (was: Needs Review)

5 years ago

db-qa03.qa.fedoraproject.org now exists, running Fedora 28 and postgresql-10.4-1.fc28

However, we probibly want to be able to contact it and use it. For that I have put in a ticket to open postgresql port to/from the openqa machines. I will update this ticket when thats done.

db-qa03.qa is now backed up and ready for service!

:minidisc:

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Thanks a lot.

I wound up not having time to get to it this cycle :/ Will try and get us up to latest shiny openQA after F29 is done.

We have now migrated openqa staging to the new server, and nothing appears to have blown up. Will migrate prod in a while.

Login to comment on this ticket.

Metadata