Project

General

Profile

action #76924

coordination #69478: [epic] Upgrade o3+osd workers+webui to openSUSE Leap 15.2

Upgrade postgresql database version on o3 to default of Leap 15.2, i.e. postgres12

Added by okurz 9 months ago. Updated 23 days ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
Start date:
2020-11-03
Due date:
% Done:

0%

Estimated time:

Description

Motivation

All our CI tests run against postgres12, see https://build.opensuse.org/package/live_build_log/devel:openQA:ci/base/containers/x86_64 , as the default postgres version within openSUSE:Leap:15.2 is postgres12 . We should use the same version for our production instances to reduce the risk of diff between production and testing environments and also to run a version that will be supported for longer

Acceptance criteria

  • AC1: o3 runs openQA from a postgres12 database
  • AC2: no severe functional or performance related impact has been observed

Suggestions

  • Research how postgres database upgrades are conducted, e.g. see #43976#note-6
  • Try it out in a test environment, e.g. container loading o3 database dump file
  • Do it in real environment
  • Monitor for functional and performance impact

Further details

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.2:Update/postgresql/postgresql.spec?expand=1
shows that the default switched to 12 whereas in https://build.opensuse.org/package/view_file/openSUSE:Leap:15.1:Update/postgresql/postgresql.spec?expand=1 it looks a bit inconsistent, mixed 10+12. However all versions up from 9.6 are still supported in openSUSE Leap 15.1 and 15.2


Related issues

Copied to openQA Infrastructure - action #76927: Upgrade postgresql database version on osd to default of Leap 15.2, like on o3New2020-11-03

History

#1 Updated by okurz 9 months ago

  • Copied to action #76927: Upgrade postgresql database version on osd to default of Leap 15.2, like on o3 added

#2 Updated by okurz 23 days ago

  • Status changed from Workable to New

moving all tickets without size confirmation by the team back to "New". The team should move the tickets back after estimating and agreeing on a consistent size

Also available in: Atom PDF